Join us on Discord!
You can help CodeWalrus stay online by donating here.

Integrate a TI Device driver in a Windows 10 universal app C#

Started by Ephraim Becker, May 08, 2015, 01:24:59 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ephraim Becker

How do I integrate TI's device driver into a Windows 10 universal app?
  • Calculators owned: TI 84 Plus, TI 84 Plus C Silver Edition, TI 84 Plus CE, Casio FX-9750 GII
I have Aspergers Syndrome

Dream of Omnimaga

I don't think it's possible, considering Windows 10 hasn't even been released yet. Also, it will probably take a very long while before anything TI-driver-related becomes possible on Windows 10, considering people can barely even get TI drivers to work under Windows 8.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Snektron

You can use your own driver, though you'd need to uninstall TI's driver
  • Calculators owned: TI-84+
Legends say if you spam more than DJ Omnimaga, you will become a walrus...


Lionel Debroux

QuoteHow do I integrate TI's device driver into a Windows 10 universal app?
You don't, for at least two obvious reasons:
* a permanent one: licensing/copyright;
* a potentially transient reason: platform support. That is, for now, TI's drivers do not support all of the platforms which could be targeted by an universal app.

QuoteYou can use your own driver, though you'd need to uninstall TI's driver
Not necessarily, as shown by libticables' drivers based on libusb: libticables' drivers and TI's drivers can work side by side if the user performs manual installation of the libusb-win32 filter driver for the targeted devices ;)
I downloaded the very first Windows 10 developer preview, and successfully checked TILP's operation on that version. I just hope the final version will behave the same (that is, it won't be even more obnoxious wrt. driver requirements).
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.

Ephraim Becker

Quote from: Lionel Debroux on May 09, 2015, 03:57:54 PM
QuoteHow do I integrate TI's device driver into a Windows 10 universal app?
You don't, for at least two obvious reasons:
* a permanent one: licensing/copyright;
* a potentially transient reason: platform support. That is, for now, TI's drivers do not support all of the platforms which could be targeted by an universal app.

Then how was TILP possible to make?
  • Calculators owned: TI 84 Plus, TI 84 Plus C Silver Edition, TI 84 Plus CE, Casio FX-9750 GII
I have Aspergers Syndrome

novenary

By reverse engineering the protocol used by the calcs. It's far from being an easy task though.

Dream of Omnimaga

TiLP was also maintained by very skilled programmers with years of experience beforehand.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

novenary

And it still is thanks to Lionel (although dev has slowed down a lot as of lately apparently, it works much better than TI connect for me).

Lionel Debroux

#8
QuoteThen how was TILP possible to make?
Given that the official driver is not a valid option, for licensing and functionality reasons, then things were made differently.
Namely, by using specific third-party drivers (as strongly hinted by my previous message). The specifics of those drivers have varied over time, and for USB devices, settled to libusb before I became the maintainer in 2009.
I contributed a patch to upstream libusb-win32, so that it provides a built-in way to handle buggy devices (read: devices which don't respect the USB standards), such as some TI graphing calculator models handled by libticables. Previously, these devices' peculiarities were handled through an unsigned fork of the libusb-win32 driver. The fact that the signed libusb-win32 driver could fulfill the purpose, after my patch, is what solved the driver issues for USB cables on 64-bit Windows 7 in TILP II 1.16. Then, Microsoft found it smart to annoy driver developers even more, in Windows 8/10, where having a signed driver binary is no longer enough, the CAT files also need to be signed. Another manual step based on Zadig, left to the user...

QuoteBy reverse engineering the protocol used by the calcs. It's far from being an easy task though.
Yeah, reverse-engineering both the cable and calculator protocols. TI EdTech does not provide official documentation about these protocols, but does obviously not attempt to prevent people from documenting them and making programs for platforms they don't want to support. In fact, they help the process a bit, by providing some cables and calculators to the developer of the libti*/gfm/tilp stack, formerly Romain Liévin and nowadays myself, at no cost.
I bought only 5 TI graphing calculators out of the ~25 I have. I don't have every single model: for instance, I have neither 92+, nor V200. 15 were picked up from Romain Liévin, a number of those were given to him by TI. My CX CAS and 84+CSE were given to me by TI, pending other models.

QuoteTiLP was also maintained by very skilled programmers with years of experience beforehand.
I know you probably didn't imply that it no longer is, and Streetwalrus beat me to stating that it still is, indeed :)
As a number of other old-timers of the calculator communities (this also occurs in the HP community), I started programming on a regular basis on (in fact, for) calculators, and became a professional software developer.

Quote(although dev has slowed down a lot as of lately apparently, it works much better than TI connect for me).
After a burst of activity leading to the release of TILP II 1.17 in March 2013, development slowed down somewhat indeed, though there were always bursts of activity every few months, if you look at the commit history. That was largely due to my day job, especially from October - November 2013.
However, development picked back up a lot since December 2014, with several major new features, especially improved 84+CSE support by Benjamin Moody, a new USB probing API by Benjamin as well, 83PCE/84+CE(-T) support (nearly complete, ROM dumping is pretty much the only missing feature) and 82A support (that calculator model sucks), both mostly by myself. Of course, besides hundreds of bugfixes, 99% of them invisible and fixing more or less minor bugs, which usually don't happen / are not an annoyance (e.g. memory leaks) under normal conditions, otherwise they'd have been reported and fixed a long time ago. The libti*/gfm/tilp code base is just like most code bases: it works well, but it's full of bugs (well, less so nowadays).
The TILP beta-testing topics are on TI-Planet and Cemetech.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.

Unicorn

Waaaait. TI gave you calculators for making a competitor of their software? O.O
  • Calculators owned: I own all of them: PICKACHUP TI 84+ CSE TI 83+ SE TI something something ??? ??? ??? ??? ???
  • Consoles, mobile devices and vintage computers owned: PICKACHUP ??? ??? ??? ??? ???



??? ??? ??? ??? ???

novenary

Wow that's good to know. I'll try out the latest dev version when I have time. The one thing that still needs improvement is Nspire support tho. Linking works fine but you can't access the whole fs.

Lionel Debroux

#11
QuoteWaaaait. TI gave you calculators for making a competitor of their software? O.O
Yes, TI EdTech did give calculators to Romain, and does it for me.
libti*/gfm/tilp is effectively complementary to TI-Connect / TI-Connect CE / TI-Nspire Computer (Link) Software: it works on Linux across many ISAs, to begin with, whereas they don't target anything but Windows and MacOS X (which libti*/gfm/tilp target as well, of course). I very much doubt TI considers libti*/gfm/tilp as any kind of serious competitor to their offerings (and even if they were... it means that they have to improve their products !).
Providing hardware to one third-party developer at a time costs them several dozens of dollars (production cost) divided by number of models (less than one on average) per year. The fact that there's a set of programs (developed by people who are doing it for no fee, during their spare time) which can communicate with TI graphing calculators on platforms they don't target (and also platforms they target) gains them far, far more than several dozens of dollars per year :)

HP has a different approach to helping third-party developers: more information, less free hardware. But HP is helping third-party developers nevertheless, because it makes perfect business sense.

QuoteThe one thing that still needs improvement is Nspire support tho.
Not just that :)
The todo/wish/bug list is far more lengthy than that. Its contents are not a secret, several important items have been posted here and there over time. It's privately distributed to several persons who act on it, but not public (at least for now), because it's large and presented in an unattractive way (a 30+ KB plain text file containing verbatim excerpts from private e-mails; yes, done items are being trimmed once in a while), and changes often.

QuoteLinking works fine but you can't access the whole fs.
* support for > 1 level of folders was recently refreshed to HEAD, improved, then added to the experimental branch in the tilibs repository (currently the first commit of that branch), but it's not readily accessible to most users until I work again on the TILP UI part of the change at some point, which is the reason why 1) it remains on the experimental branch and 2) I don't communicate much about it.
* accessing files at the root of the documents hierarchy isn't done, but users seldom do that;
* accessing files outside the documents hierarchy is not allowed by the calculator-side implementation of the commands. Not any longer, that is; OS 1.x made it possible to dump the OS through a dumb directory traversal flaw.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.

novenary

Hmmm, I was just mentioning what I personally encountered. :P Having access to the root of documents would still be sort of useful, also setting the target directory from the command line (I use tilp in scripts, especially for ndless projects).

Also maybe this conversation should be split. *prods Eiyeron*

Lionel Debroux

QuoteHaving access to the root of documents would still be sort of useful,
When I implement support for > 1 level of folders in TILP, I'll have a better idea of what it takes to achieve access to files at the root of the documents hierarchy.

Quotealso setting the target directory from the command line (I use tilp in scripts, especially for ndless projects).
You'd better using titools for scripting :)
TILP's CLI is very limited indeed, and it was worse before a suggestion of mine, implemented as part of Romain's last release.

QuoteAlso maybe this conversation should be split. *prods Eiyeron*
On the one hand, the discussion has strayed from the original question, but on the other hand, the original question, and a followup question by the original poster, have been answered.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.

novenary

Indeed.

As for titools, last time I checked it didn't work with the Nspire.

Powered by EzPortal