CodeWalrus

Development => Calculators => Calc Projects, Programming & Tutorials => Topic started by: Lionel Debroux on October 25, 2015, 04:30:17 PM

Title: TILP: beta-testing...
Post by: Lionel Debroux on October 25, 2015, 04:30:17 PM
Since the previous public build, there have been, guess what... improvements and bugfixes :)
Excerpt of the changelog:
Enter calc model (usually 13, 14, 18-21): 14
Enter raw DUSB packet as hex string of up to 4 * max raw packet size (non-hex characters ignored; CTRL+D to end):
00:00:00:2E:04:00:00:00:28:00:07:00:13:00:0A:00:08:00:02:00:03:00:04:00:06:00:07:00:09:00:0B:00:0C:00:0D:00:0E:00:0F:00:10:00:11:00:1E:00:1F:00:2D:00:4B

0000002E (04)                                                   | PC>TI: Virtual Packet Data Final
        00000028 {0007}                                         | CMD: Parameter Request
                00 13 00 0A 00 08 00 02 00 03 00 04 00 06 00 07
                00 09 00 0B 00 0C 00 0D 00 0E 00 0F 00 10 00 11
                00 1E 00 1F 00 2D 00 4B
Requested 19 (13) parameter IDs:
        000A (OS mode)
        0008 (Device type)
        0002 (Product name)
        0003 (Main part ID)
        0004 (Hardware version)
        0006 (Language ID)
        0007 (Sub-language ID)
        0009 (Boot version)
        000B (OS version)
        000C (Physical RAM)
        000D (User RAM)
        000E (Free RAM)
        000F (Physical Flash)
        0010 (User Flash)
        0011 (Free Flash)
        001E (LCD width)
        001F (LCD height)
        002D (Battery level)
        004B (Exact math engine)
The usual links:
EDIT in 2021: updated the link to the *nix install script.
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on October 26, 2015, 05:22:49 AM
I didn't know that TiLP was still maintained regularly O.O . I guess I didn't check the threads enough (since I use TI-Connect and I thought that it was just people asking for help), but I'm happy by those updates. :) Good news about the extra CE support.

Is it possible to dump ROM files from a TI-84+CE, btw?
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on October 26, 2015, 06:37:59 AM
QuoteI didn't know that TiLP was still maintained regularly O.O
Somewhat less so over the past two years and a half, but I've kept working on them, with some help by Benjamin Moody and Jonimus.
So far, there have already been more commits since TILP II 1.17 than between 1.16 and 1.17 or any previous releases that I produced, and these commits contain more changes, too.

QuoteIs it possible to dump ROM files from a TI-84+CE, btw?
Nope, for lack of a USB-based dumper which speaks the libticalcs dumping protocol.
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on October 27, 2015, 04:38:23 AM
Do you know if Floppusmaximus (Benjamin Moody) is still around nowadays? I haven't seen him anywhere in two years.


And would an USB-based dumper which speaks the libticalcs protocol be harder to implement for this calculator than it was for the CSE and 84+ due to any RSA key like with third-party flash apps, or would it be similar?
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on October 27, 2015, 09:22:29 AM
QuoteDo you know if Floppusmaximus (Benjamin Moody) is still around nowadays? I haven't seen him anywhere in two years.
Benjamin seldom attends message boards (let alone IRC chans), but can usually be reached through e-mail.

QuoteAnd would an USB-based dumper which speaks the libticalcs protocol be harder to implement for this calculator than it was for the CSE and 84+ due to any RSA key like with third-party flash apps, or would it be similar?
The libticalcs ROM dumpers have always been ASM programs :)
The 84+CSE uses the same USB controller as earlier 84+-class models, and the ROM dumper is built from the same source file, with the help of a bit of conditional compilation: https://github.com/debrouxl/tilibs/blob/master/libticalcs/trunk/src/romdump_84p_usb/romdump.z80
However, the TI-eZ80 series has a new USB controller, and AFAICT, neither the USB controller, nor higher-level ASM or C APIs which might - if they exist - make it possible to send raw bytes over the wire, as provided by AMS on the 89T and used by the 89T DUSB ROM dumper, have been documented.
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on October 27, 2015, 04:40:59 PM
That sucks. I hope that one day a ROM dumper will be possible. D: It would suck if we were stuck forever with camera captures instead of actual screenshots when showcasing our games, not to mention the lack of debugging tools.
Title: Re: TILP: beta-testing...
Post by: Adriweb on October 27, 2015, 06:28:15 PM
There are other ways (that already exist) to get a ROM dump than with tilp. It's been among one of the first things done, unsurprisingly. Just not very publicly :)
I'm sure at some point they'll become available easily.
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on October 27, 2015, 08:19:38 PM
Ah ok. Does it require extra hardware like some stuff that required the RS232/TTL adapter on the Nspire? Another nice thing would be if there was a ROM dumping program that worked on-calc, like ROM8x.
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on October 27, 2015, 09:21:25 PM
QuoteDoes it require extra hardware like some stuff that required the RS232/TTL adapter on the Nspire?
Nope, just the standard built-in functionality. As you know, there's no "extra" port (comparable to the Nspire dock port) on the TI-eZ80 series.

QuoteAnother nice thing would be if there was a ROM dumping program that worked on-calc, like ROM8x.
Such programs do not exist publicly, indeed.
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on December 30, 2015, 07:08:14 AM
Noteworthy changes since the previous build:
Known bugs:
The usual links:
EDIT in 2021: updated the link to the *nix install script.
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on December 30, 2015, 07:16:05 AM
Thanks for the cross-post. :)

I'm happy to see a CE ROM dumper. By copying data, do you mean it copies the ROM data inside a 8xp or 8xv file that you have then to open in a computer editor, then append the data at the end of a large ROM file in something like Notepad? That could definitively be a workaround for the time being, providing that the generated data chunks are large enough (eg close to 64 KB, so we have fewer file transfers to do).


Question: Does TILP still require doing some special stuff to not screw up TI-Connect installs? And will TI-Connect CE be affected as well?
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on December 30, 2015, 07:21:02 AM
QuoteBy copying data, do you mean it copies the ROM data inside a 8xp or 8xv file that you have then to open in a computer editor, then append the data at the end of a large ROM file in something like Notepad?
The current TI-eZ80 ROM dumper copies the ROM data inside a 8xp program (protected program, in fact), but that program stays in RAM without interfering without the Flash memory's contents (unlike offline rom8x-like approaches). libticalcs builds the whole Flash image automatically from the modified contents of that program, one chunk at a time, without user manual intervention :)
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on January 06, 2016, 08:05:47 PM
I guess it's a better move, because it can be annoying when you dump a ROM then launch the emulator, about to test a large game, only to find out that your ROM ended up pre-loaded with hundreds of archived games and appvars, requiring you to do a mem clear everytime you load the ROM. Thanks for explaining.
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on January 30, 2016, 04:46:02 PM
Noteworthy changes since the previous build:
Known bugs:
The usual links:
EDIT in 2021: updated the link to the *nix install script.
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on February 14, 2016, 08:38:40 PM
Do you know if there are plans to add an easy way to hack the 82 Advanced/84+T in future versions? For example, there couldd be a wizard in TiLP which automatically sends the required files to the calc.
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on February 15, 2016, 07:53:18 PM
QuoteDo you know if there are plans to add an easy way to hack the 82 Advanced/84+T in future versions?
Ah, nope, there was no such plan yet in the todo/wish/bug list. Said list has contained for a while an item which reads "TILP UI: add a menu entry for exiting the PTT mode (greyed out if not connected to a Nspire)", still targeted at the current development cycle, but no TILP wizards for installing Ndless, nLaunchy or similar tools for other platforms, by leveraging the capabilities of the underlying layers, mostly libticalcs. I don't remember seeing that particular feature request before, or thinking about it by myself :)
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on February 16, 2016, 09:13:27 AM
Ah ok. I thought it could be a nice addition, but of course it would be a lot of work, since each version of Ndless and exploit has to be installed in different manners.
Title: Re: TILP: beta-testing...
Post by: Adriweb on February 16, 2016, 09:16:06 AM
Well it's still a linking program, this tends to be out-of-scope / feature-creepy. I'm sure that anyone wanting to "hack" his 82A would be able to download whatever file(s) is required and follow the procedure as the author explains it, with tilp or something else.
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on March 29, 2016, 08:29:37 PM
Noteworthy changes since the previous build:
The usual links:
EDIT in 2021: updated the link to the *nix install script.
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on March 29, 2016, 08:37:59 PM
Does DUSB stand for Direct USB? Also, what is the RLE compression for? I know what it is, but I wonder what is the use in TILP case. Thanks for the update. :)
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on March 30, 2016, 05:53:13 AM
* yup, DUSB is libticalcs' unofficial name for the 84+/84+CSE/83PCE/84+CE/82A/84+T/89T protocol. The two other protocols are dubbed DBUS (legacy I/O port) and NSP.
* the use case for exporting these two RLE screen uncompression functions isn't that obvious indeed. The trigger was that I wanted to uncompress a Nspire RLE screen directly from test_ticalcs_2 - I was trying out a modified version of calc_nsp.c::recv_screen()) - and the makers of TI-Viewer might find it useful too. While at it, I exported the 84+CSE RLE screen uncompression function, made by Benjamin Moody, which was previously hidden as well in the 84+ family support code.
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on March 30, 2016, 03:44:05 PM
Oh god, I think this could lead to some confusion if both are named DUSB and DBUS. BUt it's fine, lol. :P

As for screen compression, thanks for explaining. I wasn't sure if it meant that screen content was compressed before actually being sent to the LCD in real-time or something else (if that was the case with the CSE then that could have explained why it's so slow :P)
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on March 30, 2016, 05:38:27 PM
If the 84+CSE didn't compress screenshots before sending them to the computer, the process of taking screenshots would be even far slower, as the amount of data is simply large, and there's no hardware acceleration.
The 84+CE/83PCE reverted to raw screenshots, but transferring them is quite fast, thanks to hardware acceleration.
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on March 31, 2016, 05:27:13 AM
Ah, that explains it. I wondered what it was for. Thanks for the info. It's interesting, though, because I was sure that the compression process would be much slower than sending the content uncompressed.
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on April 05, 2016, 08:27:52 PM
Noteworthy changes since the previous build:
The usual links:
EDIT in 2021: updated the link to the *nix install script.
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on April 06, 2016, 03:43:21 AM
Wow, I didn't know that Boscop was still around. O.O

Thanks for the update :)
Title: Re: TILP: beta-testing...
Post by: utz on April 06, 2016, 08:39:24 AM
Thanks Lionel, I very much appreciate your hard work!
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on April 30, 2016, 02:34:56 PM
Minor changes since the previous build:
The usual links:
EDIT in 2021: updated the link to the *nix install script.
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on May 01, 2016, 07:09:19 AM
Good move to separate the calculator models. Although they have some compatibility (eg 8xp files can be sent to any) they are still way different hardware-wise, especially the 84+CE.

As for Nspire key codes, is that to control TiLP from the calc or vice-versa?
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on May 01, 2016, 07:41:08 AM
QuoteGood move to separate the calculator models.
Yup, though for now, this one is a non-functional change. It's just paving the way for potential future differences.

QuoteAs for Nspire key codes, is that to control TiLP from the calc or vice-versa?
Controlling the calculator from the libraries underlying TILP. Multiple TI-Z80, TI-68k and TI-eZ80 models use remote control for ROM dumping; libticalcs could also be used for TI-Remote - in fact, libticalcs originally grew the ability to send keypresses to the Nspire, using a Nspire-specific method (rather than the generic method I modified here for Nspire support, though it's a minor ABI break), before TI-Remote was released, thanks to USB packet dumps gathered by Adriweb from the private beta.
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on May 01, 2016, 02:13:21 PM
I see. That could definitively become useful :)
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on October 09, 2016, 06:10:09 PM
A bunch of changes since the previous build:
This build is noteworthy in that it is probably the last beta build before the long overdue release of TILP II 1.18 :)
As such, and even if I know that very few people use TILP or its libraries, testing would be appreciated.

The only remaining item for the current development cycle is adding clock getting / setting support for the TI-eZ80 series, which was made possible by the DUSB PID documentation work from the past few weeks. Not a task for this week-end, though.

The usual links:
EDIT in 2021: updated the link to the *nix install script.
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on October 10, 2016, 04:46:15 AM
Awesome Lionel. Something I am curious about is how the transfer speed compares to TI-Connect CE. TI-Connect was very slow, but TI-Connect CE improved things considerably, so I was curious about if TILP managed to push things even further. Also, can it do ROM dumps for the TI-82 Advanced and TI-84 Plus-T?
Title: Re: TILP: beta-testing...
Post by: 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.
Title: Re: TILP: beta-testing...
Post by: p2 on October 11, 2016, 03:29:43 PM
I know this is not really about beta testing...
But it would be really great if there was an easier way to set up TiLp on different Linux distributions as it took me multiple hours to get it done the last time...  :ninja:
Btw will TiLp one day be availagle in the official download center (that GUI that makes it that much easier than manually doing it over terminal)? :)
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on October 11, 2016, 03:42:57 PM
QuoteBtw will TiLp one day be availagle in the official download center (that GUI that makes it that much easier than manually doing it over terminal)? :)
By now, TILP is packaged by at least Debian / Ubuntu / Mint / their many derivatives (alberthro), Arch (Jonimus et. al), Fedora (TC01) and OpenSUSE (Vogtinator). I might have forgotten one when writing this post. IOW, it is part of the official download center for the main end user distros :)

However, the fact is that the latest official release - which is packaged by distros, most of them do not package from the development sources - is nearly always hopelessly outdated. Even when there was a year +/- several months between releases, as occurred for TILP II 1.14-1.17, past the first few weeks after a release was cut, the version in the SCM (formerly SVN, nowadays Git) contained a bunch of new features and bugfixes made since the official release.
The changes in the upcoming TILP II 1.18 release train over the 1.17 release are by far larger than the changes between any two consecutive release trains in 1.13-1.17. Yes, I really should have made at least 2 releases since April 2013 :)

Compiling from source, which is easy with the install_tilp.sh script (especially nowadays that I went out of my way to provide copy-pastable lists of build dependencies for multiple distro families), is what I tend to tell users of distro packages when they experience some unwanted behaviour, unless I know that this won't change anything (e.g. because I didn't modify that particular area since then). This is common behaviour for open-source / free software projects, not just for libti*/gfm/tilp.
Title: Re: TILP: beta-testing...
Post by: p2 on October 11, 2016, 03:56:37 PM
For some reasons I couldn't find it on Mint when I wanted to install TiLp...
Had to do it manually using the terminal but at least someone sent me a script that did SOME of the work for me (but still had to manually get like a thousand dependecies) xD
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on October 11, 2016, 04:02:25 PM
QuoteHad to do it manually using the terminal but at least someone sent me a script
Yup, the script linked above.

Quotethat did SOME of the work for me
Attempting to detect the exact flavour and version of the Linux distro currently executing a script, and attempting to support the most relevant subset of distros is a significant pain and amount of work. Really :)

Quote(but still had to manually get like a thousand dependecies) xD
Yes, dozens of packages when counting the transitive dependencies. But at least, the script tells you which ones to download for the most popular distros ;)
Title: Re: TILP: beta-testing...
Post by: p2 on October 11, 2016, 04:04:59 PM
yess it was a great help the script told me that  :thumbsup:
It was just like "oh god... not again... aaaahh" each time I got a new "YOU NEED THIS PACKAGE FIRST" message... xD

And as I experienced myself what a pain it is doing it for only one distro... I dont even want to imagine how much work it is creating a script that does all that automatically and for multiple distros >.< Big thanks for you guys putting so much work into that!!  :love:
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on October 11, 2016, 04:26:27 PM
QuoteI dont even want to imagine how much work it is creating a script that does all that automatically and for multiple distros
It's high indeed. The first step in the distro type + version detection automation was obtaining the relevant lists of packages, which I eventually did through Docker containers, so that I didn't have to install the whole distros in VMs. Attempting to auto-detect the distro would be the second step, but much work. I suppose I'd borrow from install scripts I saw over time, e.g. the install script for SDR stuff, but still.
Title: Re: TILP: beta-testing...
Post by: p2 on October 11, 2016, 04:31:50 PM
I begin to understand...
People keep saying Linux sucks because it's so much work to install only a single program... (I did myself)
I finally begin to understand WHY many developers don't change something about it  9_9
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on October 11, 2016, 04:41:01 PM
QuotePeople keep saying Linux sucks because it's so much work to install only a single program... (I did myself)
And yet, it's so much easier to install a single program from the C/C++ source code in Linux or MacOS X than it is in Windows, that it isn't funny :D
Yes, seriously. Downloading build dependencies on Windows is so much of a pain that in fact, Microsoft recently created its own project to do exactly that, after users requested for many years that Microsoft provide something as good as the Linux package managers (apt and friends), or homebrew (third-party) for MacOS X. I forgot about the name of Microsoft's project.

QuoteI finally begin to understand WHY many developers don't change something about it  9_9
Amount of free time for many developers, yeah... I've never been paid to work on libti*/gfm/tilp, though it's a fact that I bought only a small subset of my calculator collection by myself, especially because I picked up 15 calculators from Romain Liévin a little while after becoming the maintainer, and that TI paid for most of my trip to their office in Paris in 2011.
Title: Re: TILP: beta-testing...
Post by: p2 on October 11, 2016, 04:55:50 PM
wait... you went to paris to visit some TI officials or something? O.o
THat sounds like an interesting story ;D

Did they love you or did they hate you for creating TiLp...?  <_<
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on October 11, 2016, 06:14:59 PM
* yes, I went to TI's office in Paris once in 2011, and I met critor and Adriweb there (for the only time, so far) for a meeting with TI EdTech people, two of them being high-level executives. That was documented on TI-Planet at the time, IIRC, but probably in French only. On his side, Romain once went to TI EdTech's office in Dallas.
Amusingly, I had met Adriweb's father in a completely unrelated event, the year before.

* I didn't create TILP, Romain Liévin and Julien Blache did at the end of the 1990s, a decade before I became the maintainer :)

* TI is far from hating the work Romain, Julien, I and contributors (Benjamin Moody, Jonimus, etc.) did and still do on our free time :)
The TI EdTech stance is not to provide documentation about their "modern" (2004 and later) protocols and file formats, or even full documentation for their older protocols and file formats. So they're not trying to help the making of what we TI community dub "calculator linking software" (in HP parlance, it would be more like "connectivity kit") by providing information.
However, they're clearly not trying hard to hamper third-party efforts finding information by themselves (through reverse-engineering for interoperability purposes, which is perfectly legal in pretty much any country, all the more it's non-commercial as far as we're concerned) and providing programs for platforms both not supported (Linux, the BSDs) and supported (Windows, MacOS X) by TI EdTech, either.
They're even helping a bit, as a matter of fact: they gave calculators and cables to Romain in the past, which were invaluable to him for adding support for the 89T/84+ and Nspire USB protocols . They gave several calculators to me since 2011, the first one being the CX CAS, which enabled me to add Nspire CX / CM (CAS) color screenshot support in libticalcs several days later. They don't require NDAs, I never signed any form of NDA with TI (or anyone else, for that matter).
Title: Re: TILP: beta-testing...
Post by: p2 on October 11, 2016, 07:04:52 PM
wow I'm really surprised as I only got negative news about TI like making it impossible to downgrade the calcs and stuff like that.
How comes they on he one hand support people like you but on the other hand try to lock out some of our stuff?
Title: Re: TILP: beta-testing...
Post by: Adriweb on October 11, 2016, 07:22:19 PM
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
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on October 11, 2016, 07:35:05 PM
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 ^^
Title: Re: TILP: beta-testing...
Post by: p2 on October 11, 2016, 07:44:57 PM
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 :)
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on October 11, 2016, 08:15:09 PM
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.
Title: Re: TILP: beta-testing...
Post by: Adriweb on October 11, 2016, 08:24:07 PM
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
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on October 11, 2016, 08:26:52 PM
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.
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on June 05, 2019, 07:02:12 AM
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:
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 https://build.opensuse.org/project/show/home:debrouxl:TILP .

Next up:
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on June 06, 2019, 05:59:16 PM
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.
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on June 26, 2019, 08:10:31 PM
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, https://tiplanet.org/beta/tilp2-setup.exe . I haven't tested it on a real Windows install. The aforementioned changes, and more, are available :)
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on June 28, 2019, 04:39:31 PM
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.
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on July 14, 2019, 06:54:39 AM
I have produced another build, available from https://tiplanet.org/beta/tilp2-setup.exe 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 https://github.com/debrouxl/tilibs/tree/experimental2/libticalcs/trunk/tests 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...
Title: Re: TILP: beta-testing...
Post by: Lionel Debroux on September 11, 2023, 08:02:42 AM
More than 4 years since my latest update... how time flies.
No new beta build for Windows, but on the experimental2 branch of the tilibs repository, among other things, libti* now have initial support for a currently undetermined subset of the CX II series (at least OS 5.0.0.1509 and 5.2.0.771 work) :)
That was after receiving a report ( https://github.com/debrouxl/tilp_and_gfm/issues/33#issuecomment-1712845038 ) that the CX II can speak the NavNet protocol ("NSP", in libticalcs parlance) used by all older Nspire models, after switching it to the alternate USB configuration. In the default configuration, it speaks NNSE, which is a variant of NavNet wrapped with new headers and using UDP checksums. NNSE remains unimplemented in libticalcs.
Title: Re: TILP: beta-testing...
Post by: Dream of Omnimaga on October 05, 2023, 10:50:34 PM
I'm glad this is still maintained and that CX II support is gradually being added. I wonder how feasible it would be to have a Chromebook version? I would never use it but I notice that in USA many students have those abominations now and they often have troubles with the existing connectivity tools.