Since the previous public build, there have been various improvements and bugfixes, as usual Smile
For instance:
* libticonv, libtifiles, libticables, libticalcs: added ~18 free()-type functions to the API, for symmetry with the functions which allocate something - not that the libti* implementations can get rid of glib, but clients will experience less of a need to use glib functions directly due to asymmetry in the libti* APIs;
* libtifiles: added 4 new certificate parsing functions, mentioned earlier;
* libticalcs: improved thread safety by getting rid of local static variables scattered into multiple files;
* libtifiles: cleanups and code consolidation in file I/O and types code;
* libticonv, libtifiles, libticalcs: 6 new functions moved and improved from titools and TILP;
* libticonv, libtifiles, libticables, libticalcs: updated the AUTHORS files, as suggested by Fabian "Vogtinator" Vogt and Adrien "Adriweb" Bertrand;
* scattered bugfixes (memory errors, etc.).

Items are getting resolved, but the todo/wish/bug list file keeps growing...

The usual links:
* Windows installer download: http://tiplanet.org/beta/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://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.
File transfer rate is locked at 255 kbps.


Is this intentional?
Transfer rate computation is an area of libticables I'm not familiar with, the answer is in the code Smile

With the USB cables, transfer rate values produced by libticables and displayed by TILP are an indication of the transfer submission rate on the computer side, but clearly, the reception rate on the receiver is lower.
Since the previous public build, there have been, guess what... improvements and bugfixes Smile
Excerpt of the changelog:
  • internal: added per-handle pre / post receive and pre / post send hooks functionality. It's the foundation for more interesting stuff which shall be implemented later.
  • added DUSB packet dissection to libticalcs and CLI front-end to it. It makes it possible to input packets straight of, say, Wireshark, and have them analyzed in a human-readable way:

    Code:
    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)

  • added automatic detection of 83PCE vs. 84+CE. When USB scan at startup is enabled (it has been by default for years), TILP will now correctly detect 84+CE calculators, which used to be detected as 83PCE calculators. This item was implemented thanks to the previous feature;
  • added 7 new functions related to screenshots: one receives and converts the result to RGB888, five convert raw screenshot data from the calculator to RGB888 (four of them used to be part of TILP, but they belong to libticalcs), and the last one is a helper for freeing screen data returned by ticalcs_calc_recv_screen() and ticalcs_calc_recv_screen_rgb888() (part of the ongoing software engineering work to abstract the memory allocator behind libti*, so that clients have fewer hard-coded g_free() calls).


The usual links:


EDIT in 2021: updated the link to the *nix install script.
Noteworthy changes since the previous build:
  • addition of a 83PCE/84+CE ROM dumper. While the USB controller and software are still undocumented, which prevents from making a ROM dumper using the custom libticalcs dumping protocol, one of the possible workarounds is to copy data to a file, and transfer the file to the computer, repeatedly. It's slow, but it works. The calculator-side dumper was made by jacobly, the computer side by me.
  • receiving files of peculiar sizes from the TI-eZ80 series fixed, reported by jacobly;
  • split most of the code of dbus_recv() to dbus_recv_header() + dbus_recv_data(). Indirectly suggested by a discussion with SirCmpwn.
  • small improvements and bugfixes, as usual

Known bugs:
  • the colors in screenshots from color calculators look funny. Probably a byproduct of "libticalcs: add bitmap (screen) conversion functions, add ticalcs_calc_recv_screen_rgb888() and ticalcs_free_screen(), add torture tests, replace a number of Glib function calls by indirect equivalent calls." and the corresponding change on the TILP side, I'll need to investigate.

The usual links:


EDIT in 2021: updated the link to the *nix install script.
Noteworthy changes since the previous build:
  • initial support for the TI-84 Plus T, which was mostly a copy-paste-modify job.
  • several patches by Benjamin Moody containing bugfixes and improvements: version byte handling, faster calculator probing at TILP startup, better handling of non-ASCII TI-(e)Z80 app names.
  • new APIs, e.g. length-limiting versions of 4 libticonv APIs, which make it possible to simplify code in e.g. libticalcs, or more helper functions related to calculator model in libticonv.
  • fixing an old bug report through a two-liner in TILP + a new capability in libticalcs: hiding the non-silent receive and send operations on models which don't support them.
  • two new empty (unimplemented) cables: raw (no metadata such as length) TCP client and TCP server cables.
  • a range of improvements and bugfixes (screenshot color fixes, compiler warnings, translations, others), as usual.

Known bugs:
  • Benjamin Moody reported that the DBUS memory backups have been broken since a commit of mine in July 2014, which fixed other bugs - namely, memory access errors. I haven't finished fixing them yet.

The usual links:


EDIT in 2021: updated the link to the *nix install script.
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:



EDIT in 2021: updated the link to the *nix install script.
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:



EDIT in 2021: updated the link to the *nix install script.
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:


EDIT in 2021: updated the link to the *nix install script.
A bunch of changes since the previous build:
  • reduced some internal code duplication and exported yet more functions to users (under no promise of backwards compatibility);
  • communication fixes for MacOS X with especially the Nspire, by Adriweb;
  • changes and code-based documentation related to requesting information from DUSB TI-Z80, TI-68k and TI-eZ80 calculators. A significant number of previously undocumented parameters, some of which are useful, came to light;
  • other bugfixes and improvements;
  • rebuilt against a newer version of the external libarchive library, namely version 3.2.1, containing a bunch of security fixes.


This build is noteworthy in that it is probably the last beta build before the long overdue release of TILP II 1.18 Smile
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.
It seems like some commit broke clock setting on the TI-89 Titanium. I don't have time to check which commit broke the clock setting right now.




I commented out lines 97-100 in tilp_and_gfm/tilp/src/clock.c
and I can sync to PC (the synced time is 1 hour behind, probably because of Daylight Saving Time...)
but the time won't display correctly:


Thanks for the report.
The commit which broke the code is probably c05d75c70ca12406ee91b376199d6937657f8d7f.
get_clock() in https://github.com/debrouxl/tilibs/blob/master/libticalcs/trunk/src/calc_89t.c is now openly wrong on lines 943-946, 949, 974-976.

EDIT: I pushed a tentative fix on the "experimental" branch. For the first time in a while, I don't have my 89T around with me... right at a time I'd need it for testing code changes Smile
The same situation is still happening on the experimental branch. (of both tilp_and_gfm and tilibs)

I'll have some more time to check out the issue this weekend.
during the set up process it says "Sorry the files could not be downloaded. Click 'Retry' to try downloading again, or click 'Cancel' to terminate setup." ive checked my firewall settings and its not blocked. any suggestions.
Thanks for the report.
The installer attempts to download the following file:
http://downloads.sourceforge.net/project/gtk-win/GTK%2B%20Runtime%20Environment/GTK%2B%202.24/gtk2-runtime-2.24.10-2012-10-10-ash.exe?use_mirror=autoselect
which I've just tried to download four times in a row with wget, and sure enough, it worked.

I can see that some of these download attempts were redirected from HTTP to HTTPS, which is a good thing... but maybe the downloader I'm using inside the InnoSetup installer doesn't support that, doesn't like the certificate presented by the server, or something along those lines.

Does the new http://tiplanet.org/beta/tilp2-setup_https.exe installer's download ability work better ?
(that was made from HEAD of the master branch of tilp_and_gfm and HEAD^ of the experimental branch of tilibs, plus single-character change to switch from http to https in tilp2_cross.iss)
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 Smile
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 Sad ;
    • 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 the information Smile


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:
  • 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.
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 Smile
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 Smile

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 Smile

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...
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) Smile
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.
  
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 Previous  1, 2, 3, 4, 5, 6, 7
» View previous topic :: View next topic  
Page 7 of 7
» 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

 

Advertisement