Alternatively, join us on Discord.
You can help CodeWalrus stay online by donating here.

TILP: beta-testing...

Started by Lionel Debroux, October 25, 2015, 04:30:17 PM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.


October 11, 2016, 07:22:19 PM #45 Last Edit: October 11, 2016, 07:33:25 PM by Adriweb
Well, giving away a few marketing calcs to help create a (mostly-)Linux calc connectivity software is hardly counterproductive, quite the contrary ;)
And it also have nothing to do with other decisions like the anti-downgrade and security measures on the Nspire, which are pretty much imposed by exam boards. It's not even the same people dealing with that.

It also helps that we're from TI-Planet, which TI (and even more so TI-France) has known for some time now, not some random people trying to get free products for obscure reasons. The quality of review articles when we're given samples to try out, for instance, speaks for itself, I suppose.

In general, it's much easier to see negative criticism everywhere because it stands out easily - that doesn't mean there's no good too :) There are many nice things happening that lots of people don't know about. Personally, I"ve had the opportunity, several times even, to meet with TI developers, managers, etc. It's extremely enriching to be able to grasp the point-of-view of "everyone" involved in this world. Being too biased (one way or the other) doesn't do much good... and also good communication is key. Too bad it's not happening more often with TI and the community, for instance, only a few of us have been able to get to talk to them directly.

Anyway, this thread is slowly going off-topic :P
Co-founder & co-administrator of TI-Planet and Inspired-Lua

Lionel Debroux

October 11, 2016, 07:35:05 PM #46 Last Edit: October 11, 2016, 08:25:39 PM by Lionel Debroux
Quotewow I'm really surprised as I only got negative news about TI like making it impossible to downgrade the calcs and stuff like that.
It's probably because their annoying, counter-productive and nasty roadblocks to usage of their calculators are much more important, for usage by actual end users. Like nearly everybody in the community, I thoroughly hate their moves which rub users the wrong way. But it wouldn't be fair for me not to mention that for the narrow purposes of communication with calculators and interoperability with TI's official software (which is, fundamentally, this topic's focus), the situation could be worse. Sure, TI should provide documentation (their competitors usually don't, so they'd probably edge them out even further that way), and I wish I could be paid for working on libti*/gfm/tilp for several weeks to make significant progress on the todo/wish list (I need a rest on my free time, and I'm already not having enough of it)... but I bought only about 6 (5 TI, 1 HP Prime) of my ~26 graphing calculators; before that, Romain didn't buy all of his calculators and cables; and TI is pretty much all for me + contributors carrying on the work.
The next maintainer of libti* (or a replacement for it ?) should logically inherit at least the relevant part of this collection, when I pass the baton.

QuoteHow comes they on he one hand support people like you but on the other hand try to lock out some of our stuff?
Supporting Romain and me only has business upsides. It's not even one calculator per year on average (in about 7 years and 4 months, I got a CX CAS in 2011, 84+CSE in 2013, 83PCE and 82A in 2015 - in terms of monetary value, these four approximately cancel the Nspire Clickpad, 84+, 89T and 83+SE I bought before picking up Romain's collection), so if the fact that there's a working, even usually pretty reliable way to communicate with TI graphing calculators using Linux or one of the BSDs yields a single additional TI graphing calculator purchase per year (!), TI still wins.

Throwing legal or technical roadblocks at me + contributors has clear business downsides. The current top-level management at TI EdTech is perfectly aware that the "TI signing key controversy" episode - sending DMCA takedown notices to users for stuff whose complete legality is crystal clear, splashing negative publicity all over the Internet, and ending on e.g. the EFF's DMCA takedown hall of shame - was a complete no-no, a path which lawyers really shouldn't have gone on, and an error which is not to be done again (at least as long as they're at the helm, I suppose).

Attempting to lock down calculators (though miserably failing at it - their best protection is in fact that hardly anybody cares) is attempting to protect business in the face of harmful reactions of the extraordinarily dumb policies of standardized testing regulation authorities, which fantasize the threat of tampering with their dumb exams. TI needs to show these counter-productive humans that they're trying to do something against their irrational fears, otherwise they would (theoretically) risk some of their models being banned from some exams, resulting in measurable sales losses. Locking down calculators stinks because it screws users and reduces the power and usefulness of said calculators, but in the current and foreseeable state of things, calculator manufacturers can't really afford not pleasing those who can have an impact on their calculator division's bottom line, by eschewing exam testing modes from new and future calculator models...
Calculator manufacturers can't just tell the standardized testing regulation authorities what we calculator users and lovers would like to tell them ^^
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.


pff even I got a piece of code into the final exams without anyone noticing it... :P
(only displaying LULZ but still I could have done it with any program)
the main problem is that schools can't afford a second set of calcs only to  used for exams... :(
But I'm glad to hear TI is much nicer that I thought :)
Anyway war sucks. Just bring us your food instead of missiles  :P ~ DJ Omnimaga (11.10.2016 20:21:48)
if you cant get a jframe set up, draw stuff to it, and receive input, i can only imagine how horrible your game code is _._   ~ c4ooo (14.11.2016 22:44:07)
If they pull a Harambe on me tell my family I love them ~ u/Pwntear37d (AssangeWatch /r/)
make Walrii great again ~ DJ Omnimaga (28.11.2016 23:01:31)
God invented the pc, satan the smartphone I guess ~ p4nix (16.02.2017 22:51:49)

DJ Omnimaga

Quote from: Lionel Debroux on October 10, 2016, 06:09:30 PM
QuoteAlso, can it do ROM dumps for the TI-82 Advanced and TI-84 Plus-T?
Nope: this would require exploiting these calculators, but the method to do so is not public :)
Having libticalcs use exploits for holes in the calculator's software is not an issue in itself, as shown by Benjamin Moody's ROM dumper for the 85 and old 82 models, or even the Nspire OS 1.x dumper, which leverages direct directory traversal.
Do you know why the method for exploiting those calculators is not public? Is it due to fear of retaliation from TI in the form of locking the calculators even more? Is it due to fears of a cease and desist letter? Or is it just due to the author not having finished the exploit itself?

As for TI themselves, they try to protect the exam mode on their calc, but I have the feeling that for monochrome models they mainly want to reduce their features for the greater glory of more expensive color calcs. Otherwise, the CE would be locked down as well.


IIRC, BrandonW's method is (so far) leaving the calc in an unusable state after the exploit, so it wouldn't be working for many things. I haven't followed that much on those calcs, but I'm not sure if he's had time to work on it more lately. Oh well, at least for now it was enough to get a dump, apparently.
There are several tools online for people to dump their own calcs, so one more is probably not going to cause a big difference, even if it's doing that by weird means (well, TI isn't giving much choice...). Plus, people who own those models are the ones not interested by calcs, most of the time, so it's likely they're not going to be the ones looking for hacks and stuff. There's far more exciting things happening pretty much anywhere else than on a 82A :P
Co-founder & co-administrator of TI-Planet and Inspired-Lua

DJ Omnimaga

Hm I see. That said, now that the 82A has been released in English in Europe as the TI-84+T, I suspect that more people might get interested by the hack over time there if the market share compared to color models is still significant.

Lionel Debroux

It's been a looong time since I posted in the various forums' TILP beta-testing topics... In the meantime, a number of things occurred, even if as usual, few are really user-visible :)
I'll have to produce a Windows build when the CX II series' handling is usable.

Among the changes:
  • Adriweb added the definitions necessary for building libti* with CMake, I merged those, and the same for TILP, which I haven't merged because I'm focusing mostly on libti* ^^;
  • the TI-eZ80 ROM dumper was improved, then fixed, by jacobly;
  • I worked a lot on the TI-68k ROM dumper:
    • fixing huge bugs in the 92 / 92 II handling code: not only I broke dirlist during a refactor, but most of all, the 92 / 92 II ROM dumper has been corrupting dumped data since 2005 at best (the code was already wrong at the time of the libticalcs 1 -> 2 switch) by destroying 8 KB of data in order to get coherent dumps on the certificate memory are... yeah, but it doesn't exist on these models :( ;
    • multiple optimisation rounds in C, before switching to pure ASM in order to optimize more, of course, but most of all be able to get rid of the dependency on a C compiler targeting the m68k. Indeed, GCC4TI's old, heavily patched m68k-coff, which doesn't work correctly when compiled with newer compilers, isn't a future-proof solution at all, and neither is Debian's standard m68k-elf, which proves to be way too buggy to be usable... One of the end results of that work will be to make the TI-68k ROM dumper unconditionally buildable by Debian, since Debian packages all of the build dependencies. In order to achieve this, I had to be creative for producing a binary in the quite peculiar Fargo II format.
  • I implemented an event system in libticables and libticalcs, which, combined with the packet dissectors I rewrote / need to finish for libticalcs, will yield much better packet dissection functionality, but also new functionality;
  • in order to benefit from stricter typing and later from a better standard library, I switched libti*'s code to C++, even though of course, I kept the external API pure C;
  • I fixed quite a bit more issues reported by the Coverity static analyzer, I had previously made other fixing rounds;
  • I added the initial support for two additional models:
    • Nspire Lab Cradle / Datatracker Cradle: untested, but we know that these behave largely like Nspires;
    • Nspire CX II: they are detected at a USB level, but for now, handled like Nspire, which is very wrong. The protocol they're using is very different from that of other Nspires (there's a wrapper on top of a modified NavNet version), but seemingly the same as the NWB's, i.e. classroom equipment for handling multiple calculators remotely. This protocol had never been reverse-engineered.
  • TI-eZ80 calculators featuring "Python On Board" capability are now reported by libticalcs - i.e. the 83PCE EP. Thanks Adriweb for giving me information :)
Also, I used previous packaging work on OBS by Fabian "Vogtinator" Vogt for development versions of libti*/gfm/tilp, the result (completely untested !) is available from .

Next up:
  • proper handling of the CX II family, using their "new" protocol. I had started the RE work, but I hadn't found the exact checksum algorithm - which Fabian, who now has a CX II, found this week, using other methods. We're going to be able to make forward progress.
  • modifying several existing commits (for instance, the DBUS dissector, which is relatively early in the stack of commits on the experimental2 branch, isn't filled in yet), and making additional tests;
  • later: initial CBL2 handling, at least detecting and reflashing the OS. We've bought one, it reached home yesterday;
  • the TILP II 1.19 + associated libs release, between two and three years after TILP II 1.18 - all these changes make there's ample reason for a release;
  • unofficial Debian/Ubuntu packaging on OBS: for now, there's only openSUSE and Fedora.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.

DJ Omnimaga

June 06, 2019, 05:59:16 PM #52 Last Edit: June 06, 2019, 06:14:55 PM by DJ Omnimaga
Wow, I had completely forgot that TILP was now supporting the TI-Nspire CX. Also nice to see this still being updated. I will probably use TILP from now on since I am on a newer Windows install with no current TI software installed.

Can TILP send/receive TI-85 files via the Silverlink cable?

EDIT: By the way, when I launched TILP, I got an error saying that iconv.dll was missing (I am on Windows 10). I had to go download it and put it on my computer manually in order to get the software to launch.

Lionel Debroux

Uh, looks like I missed your reply here... sorry. I need to check whether I'm subscribed to the topic.
* yup, TILP can communicate with the TI-85 through SilverLink and transfer variables in a non-silent way. Not much else, the 82/85 protocol is the oldest and most limited implementation of DBUS;
* in the GTK+ runtime installer, did you check the "install compatibility DLLs" (or somesuch message) checkbox ? I always do, as IIRC, it's required.

I've just produced a new version of the Windows installer, . I haven't tested it on a real Windows install. The aforementioned changes, and more, are available :)
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.

DJ Omnimaga

Thanks for the answers. I knew that the 82/85 lacked silent linking, but I am glad that those who don't have a computer old enough to feature a serial port nor can afford that $70 serial to USB adapter I saw at Staples once can send files on those old calc models.

I think I checked the DLL box but maybe I could be wrong.

Lionel Debroux

July 14, 2019, 06:54:39 AM #55 Last Edit: July 16, 2019, 06:38:08 AM by Lionel Debroux
I have produced another build, available from as usual. The main change from the previous build is the initial support for CBL / CBR / CBR2 / CBL2 / LabPro (/ TI-Presenter, hopefully) probing; also, I have greatly expanded the functionality and scriptability of the test_ticalcs_2 CLI tool, which is helping me a lot making tests, and packaged it in the TILP installer.
Not that in itself, the lab equipment support will be useful to many people, especially in this state, but it would be great if other people could help check that the support for other models has not regressed :)

The implementation of even this reduced support for older lab equipment was much more complex and time-consuming than I originally imagined. The newest of those lab equipments implement the version DBUS command, so it's easy to detect them, but the CBL, CBR and CBR2 don't. For those, and for meaningfully communicating with the CBL2 and LabPro as well anyway, an equivalent of the Send and Get TI-Basic commands is required. On the wire, those use an area of the DBUS protocol which was basically undocumented in the linkguide (which I've read for the first time in years, and I don't maintain), and unimplemented in libticalcs, so I'm not sure it was reverse-engineered before. TIEmu and TilEm's support for communicating with real calculators through cables, thanks to the libti* stack, were invaluable in gathering traces of the emulated calc <-> lab equipment communication :)

The commit adding lab equipment communication and expanding test_ticalcs_2 currently makes the code base grow by over 3K raw lines of code + test scripts (see for those) + build definitions. Yet, I only implemented support for the computer faking a TI-68k calculator; depending on the calculator model, the TI-Z80 series probably uses at least two variants of another protocol, as I saw two different formats for floating-point numbers. Also, I only implemented support for exchanging lists, wheras scalar expressions, indexed access in lists and matrices, sometimes strings and even pictures are supported for Get in most or some conditions... and even the list parser is simplistic: no support for spaces around '{', ',' and '}', no support for '.' (effectively restricting lists to integer values).
The fact that there's no portable, thread-safe way to parse strings containing floating-point numbers with a decimal point hard-coded to '.' - that's what the lab equipment sends to TI-68k calculators - is very annoying. At work, for that same purpose, I used a non-portable and probably thread-safe solution based on creating a new instance of the C locale and using strtod_l(), because it's in a code base which only targets Linux... but I can't do that here. The function names are different on Windows, which can be worked around, but then there are all of the other *nix that libti* support...
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.

Powered by EzPortal