TILP: beta-testing...

u/Lionel Debroux 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

u/Dream of Omnimaga 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.

u/Adriweb 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.

u/Lionel Debroux March 29, 2016, 08:29:37 PM

Noteworthy changes since the previous build:

patches by Benjamin Moody to e.g.:

fix multiple occurrences of breakage and handle version numbers in TI-Z80 DUSB backups;
support TI-Z80 DUSB backups;
fix and expand TI-Z80 key code definitions;

cleanups of mine which factor out duplicated code in the 82/85, 86, 83 support code and the 89/89T/92+/V200, 92 support code - this also helped performing...
... the final removal of those ugly TRYF macros, originally 1000+ occurrences, splattered across the code base: immediate return from the middle of functions, irrespective of necessary data cleanups;
further improved thread safety by removing more file-local variables shared across handles;
new features: exporting the Nspire and 84+CSE screen RLE uncompression function from libticalcs;
build fix on Alpine Linux (musl libc);
installer rebuilt with InnoSetup 5.5.9 dev (contains important InnoSetup security fix) and renamed to tilp2-setup.exe.

The usual links:

Windows installer download: http://tiplanet.org/beta/tilp2-setup.exe .
Source code: https://github.com/debrouxl/tilibs (experimental branch) + https://github.com/debrouxl/tilp_and_gfm (experimental branch).
Install script for anything non-Windows which is handled by TILP: https://ti-pla.net/tilpinst , https://github.com/debrouxl/tilp_and_gfm/blob/master/tilp/trunk/build/scripts/install_tilp.sh .

EDIT in 2021: updated the link to the *nix install script.

Last Edit: October 02, 2021, 07:07:04 AM by Lionel Debroux

u/Dream of Omnimaga 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.

u/Lionel Debroux 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.

u/Dream of Omnimaga 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.

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

)

u/Lionel Debroux 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.

u/Dream of Omnimaga 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.

u/Lionel Debroux April 05, 2016, 08:27:52 PM

Noteworthy changes since the previous build:

Fixed variable transfer to TI-68k through DBUS protocol, and several other operations on multiple DBUS platforms, which I broke several months ago. Reported by TI-68k old-timer Oliver "Boscop" Hoog on #ti;
Synchronized the send_var and send_var_ns implementations, which fixed three minor implementation discrepancies spotted by looking at multiple implementations side by side; while at it, made the code cope better with outright invalid data structures which might be passed to libticalcs by evil users (libtifiles obviously doesn't generate such weirdness) and trigger nullptr derefs and OOB writes.

The usual links:

Windows installer download: http://tiplanet.org/beta/tilp2-setup.exe .
Source code: https://github.com/debrouxl/tilibs (experimental branch) + https://github.com/debrouxl/tilp_and_gfm (experimental branch).
Install script for anything non-Windows which is handled by TILP: https://ti-pla.net/tilpinst , https://github.com/debrouxl/tilp_and_gfm/blob/master/tilp/trunk/build/scripts/install_tilp.sh .

EDIT in 2021: updated the link to the *nix install script.

Last Edit: October 02, 2021, 07:07:26 AM by Lionel Debroux

u/Dream of Omnimaga April 06, 2016, 03:43:21 AM

Wow, I didn't know that Boscop was still around.

Thanks for the update

u/utz April 06, 2016, 08:39:24 AM

Thanks Lionel, I very much appreciate your hard work!

u/Lionel Debroux April 30, 2016, 02:34:56 PM

Minor changes since the previous build:

implement a suggestion from Benjamin Moody which has been on the wish list for a while: use separate calculator models for monochrome models and color models in ticonv_varname_{to,from}_tifile;
make it possible to send Nspire key codes through ticalcs_calc_send_key(): widen the key code argument from uint16_t to uint32_t, add Nspire key definition files

The usual links:

Windows installer download: http://tiplanet.org/beta/tilp2-setup.exe .
Source code: https://github.com/debrouxl/tilibs (experimental branch) + https://github.com/debrouxl/tilp_and_gfm (experimental branch).
Install script for anything non-Windows which is handled by TILP: https://ti-pla.net/tilpinst , https://github.com/debrouxl/tilp_and_gfm/blob/master/tilp/trunk/build/scripts/install_tilp.sh .

EDIT in 2021: updated the link to the *nix install script.

Last Edit: October 02, 2021, 07:07:56 AM by Lionel Debroux

u/Dream of Omnimaga 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?

u/Lionel Debroux 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.