I peformed the somewhat unrelated changes in ticables.c when integrating the libusb 1.0 backend. I wouldn't have done them if it were not for the libusb 1.0 hunks: I don't like increasing the number of commits with pure-reformatting changes

Any ideas as to why directlink with the 84+ broke? I can't see any reasons for it but something is definitely wrong. I have a feeling it maybe a change you made somewhere else in the lib and not actually an issue USB side. At least I'm not seeing any USB related errors.

Nope, I'll have to test again on my side.
At least, I haven't committed anything to SVN that would break anything in 84+ DirectUSB.

Lionel, I realized that once again I failed to get you those incrementally-sized files, do you still need them?

Yup, I still need them, even if I haven't fixed the 89T handling code either yet
TIA.

Well I did some digging and it seems libticables is claiming the TI-84+'s Buffer Size Negotiation packet as invalid but according to the DUSB docs it is perfectly valid. 0x00000004 0x01 0x000000fa is the exact packet being sent by the calc, assuming I am reading the wireshark output correctly, and from what I can see it is identical to one of the example buffer size packets in Ben's DUSB docs.

I'll dig a bit more but I'm not sure what could possibly be the issue here, and why it only happens with the TI-84+ and not the 89Ti.


Edit: a bit more digging shows that the calc is sending the ack and then buffer size negotiation and the code is only handling the buffer size negotiation packet is being send to receive var header. I'm not sure when why or how this broke but from what I can see none of this code has been touched recent, so why isn't it working now?

Edit2: It seem my 89T still works as it doesn't do the buffer allocation request for the dirlist recv, I really am confused as to why this is happening on the 84+ considering we haven't touched any of this code, all of the packets are sending and receiving fine.

Edit3: Even more odd is I can send things via DUSB just fine, its only receiving that is failing. Looking through svn history I don't see any changes that would break things so I am utterly confused as to what and why this is happening.

Earlier this week, I have transferred about a thousand of files between 2 and 2560 bytes, generated by Kerm's Python program, to and from a 84+ DirectLink. That allowed me to fix sending files to the 84+ through DirectLink, the 84+ requires additional packets for some sizes just like the Nspire and 89T do
Sending to the 84+ through DirectLink remains troublesome for files of sizes 1742 bytes (the size of MobileTunes 3, which was the cause of the bug report in another topic), and I saw that 492-byte files failed as well. 1742 - 492 = 1250 = 5 * 250, and I checked that 742, 992, 1242 and 1492-byte files can't be transferred either, while files 1 byte bigger and 1 byte smaller can be.

Maybe sending files to the 84+ has a problem at a lower periodicity, but this periodicity doesn't kick in before at least 512 bytes. On the 89T, one side (or both ?) of the problems didn't kick in before a bit more than 1024 bytes.
I see you're asleep by now, but it would be interesting that you post the file you're trying to transfer to the 84+

Glad to have been able to help with my little Python program, and best of luck tracking down this very odd glitch. Or is it indeed fixed via the sending of the additional packets?

Receiving files from the calculator is fixed by additional packets, but sending files isn't: there's something more than on the 89T and the Nspire.

The issue for me seems to be only with receiving. From what I can tell libticalcs is not doing the buffer size negotiation and thus when it asks for the first var header it is getting the buffer size request packet instead and this is what is causing my invalid packet error.

Lionel, can you perchance get me a wireshark dump of TILP II requesting a dirlist from a TI-84+ so I can see if there is a difference between that and what I am seeing

I don't have Wireshark with USB capability currently set up on this computer, so I have to set it up (which is, in fact, easy, IIRC - compiling a new libpcap).
But in the past week, I successfully performed dozens of dirlist requests, retrieving a list of up to ~700 files, to a 84+SE...

I did set up that capability on my work computer (which I bring home) under the Linux install, which I use > 95% of the time - but precisely this week-end, the internal HDD of that silly MacBook Pro is failing. I have copied the data to the replacement disk, connected through an external USB adapter - but I see that this older MacBook Pro has the defect mentioned at http://refit.sourceforge.net/help/usb_disk.html :

That's a pain in the neck, sorry to hear it. I am getting tons of firsthand experience on how horribly finicky USB is to get right; I thought ASM was already tricky to catch 95% of bugs, but this is much worse. :/

I do have an idea I can try later, I think it may have to do with some of difference in the libusb api and the stuff in the code to make sure data is read.

I might throw together a disable hacks patch so I can test the old code paths on libusb-compat.

Indeed, I performed all those operations with the 84+SE through the libusb 0.1 backend.

EDIT: oh, and the Macbook Pro is now fixed
I swapped the HDDs today at work.

I have just committed the libusb 1.0 backend for libticables to the TILP SVN repository, as r4369

A great many thanks to Jon for his work on that backend
It will relieve the pain of users of the many Linux distros that don't provide libusb 0.1 proper anymore. They have replaced libusb 0.1 proper by the 0.1 compat layer for 1.0, but that one doesn't work for the purposes of libticables...

A WIP, buggy patch for making the libusb 1.0 backend fulfill the much less common use case of TIEmu <-> real calculator through SilverLink / DirectLink.
Jon and I had left this area for "future work", instead of penalizing users of TILP on most current Linux distros until this area was done.

http://lpg.ticalc.org/prj_tilp/beta/0001-WIP-libticables-libusb-1.0-backend-support-for-async.patch

We're currently trying to upgrade the libusb DLL and SYS files for Windows, so as to fulfill the long-standing feature request that TI-Connect + TILP II, and TINCLS + TILP II, become usable side by side.
Status: TI-Connect and TILP II on the one side, and TINCLS and TILP II on the other side, can be made to both work on a given computer without having to uninstall either - in fact, they do so on my father's computer running native Win7 x64
(but I seldom have access to said computer - and in fact, at the time of this writing, it's not here anymore)

For now, it's a manual process (for which I'll try to streamline my rough notes - I think that there are two ways of achieving the effect), but it's certainly going to be possible to automate it into the installer. I need to integrate the updated INF + CAT definitions kindly generated by the INF wizard provided by the newest versions of libusb-win32, and probably add several lines to the TILP II installer. Maybe more changes currently unforeseen, we'll see.


On a side note: for a while (seemingly before I became the maintainer, two years ago), TILP has been (or should have been, because the InnoSetup installer script doesn't reference the modified binary anymore) shipping with an unmodified libusb0.sys binary. As a consequence, TILP II 1.15, and a number of earlier builds, don't work well with Nspires - and testing on the native Win7 x64 computer seems to show that it's worse than on my virtualized XP (where it was more tolerable). Nobody reported it, which shows that people using TILP for interacting with Nspires on Windows are few

Technical details: the reason why a modified binary needs to be shipped, is that the Nspire's USB controller / stack somehow doesn't like the thorough reset procedure sent to it by libusb under Windows. TINCLS sends only the first half of it, and the Nspire is fine with that; but libusb sends the full reset, and after receiving that, something is wrong with the calculator's USB state. It needs to be unplugged and plugged back in...
Romain described the problem in http://sourceforge.net/mailarchive/forum.php?thread_name=473B0743.7020705%40lievin.net&forum_name=libusb-win32-devel / [url=]http://svn.tilp.info/cgi-bin/viewvc.cgi/*checkout*/libticables/trunk/src/win32/usb/libusb-win32.html?rev=4162[/url] (can't find a way to make the forum accept this URL, sorry). The corresponding diff is the following:

Code:


Since it was not integrated at the time, we need to somehow get this patch upstream, under this form or another

I've just uploaded a first testing build of what will become TILP II 1.16, with libusb DLLs upgraded to the latest versions (a version definitely supported by the filter driver): http://lpg.ticalc.org/prj_tilp/beta/setup.exe .
Corresponding patch to the sources (which looks like crap because the new INF files seem to be UTF-16 files): http://lpg.ticalc.org/prj_tilp/beta/0001-WIP-libticables-tilp-installer-upgrade-libusb-win32-.patch .

This build was only lightly tested on virtualized 32-bit XP. Please help testing on a variety of 32-bit and 64-bit Windows versions


Rough guide (will be improved and folded into the documentation, borrowing from the DUSB gCn client guide) to installing the filter driver which enables using TI's software and TILP alongside each other, one at a time:
* see http://sourceforge.net/apps/trac/libusb-win32/wiki for downloading the filter driver installer and installing it;
* launch the filter wizard (accessible from the new entry in the Start menu) when the device (SilverLink, 84+, 89T, 84+SE, Nspire) you want to use with both TILP and TI-Connect / TILP and (TINCLS or TINCS) is plugged in;
* install the filter driver for that particular device;
* run the TILP installer.
After that, the device ought to work in both TILP and TI-Connect / TILP and (TINCLS or TINCS). Or maybe TILP needs to be installed before installing the filter driver for the target device, but I don't think that it's the proper installation flow.

If you test this build, be sure to report back success or failure
It's possible that this build does not work properly under some conditions (besides Nspire support being very finicky, as described above), though it does install and enable TILP to detect and communicate with a calculator, so it cannot be entirely broken


Thanks in advance, you'll do your fellow Windows users a favor.

I have refreshed the installer and the patch, after changing the VendorName attribute in the INF files, so that TI's drivers and TILP's drivers are easier to distinguish. Thanks to JosJuice for the test and report.