The file changes size when VBA uses it. Maybe that causes troubles?

I have uploaded a new beta-testing build for TILP

Highlights since the release of TILP II 1.14 in April:

• significant improvements to Nspire support (but wrinkles remain...): new variable deletion & folder creation capabilities, OS 2.x support (TILP II <= 1.14 doesn't work at all with those versions because TI broke something that worked with all other TI USB devices including Nspire OS 1.x), calculator ID retrieval fixed, and the brand-new capability: Nspire OS 1.x (but not 2.x) dumping,
  without having to install Ndless;
  
• UI improvements by TheStorm / Jonimus, among which are the addition of a menu at the top of the application, and the greater use of stock icons;
  
• other misc. fixes: 86 ROM dumping, dozens of compiler warnings / memory leaks / unclosed files, several user-visible crasher bugs in TILP and GFM, small updates to autotools stuff for wider compatibility.

Download link for the recompiled Windows installer: http://lpg.ticalc.org/prj_tilp/beta/setup.exe .
Enjoy


Todo/wish list before a release, as time permits:

• fixing sending Pic / GDB / Str variables to a 84+ through DirectLink (that it does not currently work is a consequence of TI breaking backwards compatibility);
• updating desktop and mime types definitions would be great;
• fixing several known wrinkles, e.g. a couple reported in this very topic (latest posts by Tribal and bwang).

Tribal and bwang, could you please post your bugs on the TILP tracker, https://sourceforge.net/projects/tilp/ ?
To be honest, before re-reading about it yesterday before posting, I had forgotten about the bug reported by Tribal... which is harder to do if the bug is visible on the tracker
Thanks in advance

Thanks

EDIT1: I'm completely at loss about the reasons why the calculator refuses this particular file (even if renamed to let only one dot in the filename), while it accepts just fine e.g. a 1.3 MB TI-68k OS file (renamed to have a .tns extension, with or without multiple dots in the filename) !

EDIT2, 10 minutes later: this file is 32812 bytes, and it won't transfer. If I make it 32813 bytes, it transfers. If I make it 32811 bytes, it transfers. Very interesting.

EDIT3, 5 minutes later: the same behaviour happens with files containing all zeros: 32811 and 32813 bytes work, 32812 bytes doesn't work. Therefore, it seems that TILP (the underlying libraries, actually) somehow doesn't like this particular size. Now to find the periodicity of the size problem, if any.

EDIT4, more than half an hour later:

• files of 32554-32558 and 32560 bytes work, 32559 bytes doesn't work. 32812-32559=253=maximum size of a packet-1. 32559-253=32306 bytes doesn't work either.
• 32812 mod 253 = 175. Files of 174, 176, 427 and 429 bytes work, while files of 175 bytes and 428 bytes don't work.

So there's a problem with files whose size modulo 253 is 175. And I don't know why yet.

Thanks

EDIT1: I'm completely at loss about the reasons why the calculator refuses this particular file (even if renamed to let only one dot in the filename), while it accepts just fine e.g. a 1.3 MB TI-68k OS file (renamed to have a .tns extension, with or without multiple dots in the filename) !

EDIT2, 10 minutes later: this file is 32812 bytes, and it won't transfer. If I make it 32813 bytes, it transfers. If I make it 32811 bytes, it transfers. Very interesting.

EDIT3, 5 minutes later: the same behaviour happens with files containing all zeros: 32811 and 32813 bytes work, 32812 bytes doesn't work. Therefore, it seems that TILP (the underlying libraries, actually) somehow doesn't like this particular size. Now to find the periodicity of the size problem, if any.

EDIT4, more than half an hour later:

• files of 32554-32558 and 32560 bytes work, 32559 bytes doesn't work. 32812-32559=253=maximum size of a packet-1. 32559-253=32306 bytes doesn't work either.
• 32812 mod 253 = 175. Files of 174, 176, 427 and 429 bytes work, while files of 175 bytes and 428 bytes don't work.

So there's a problem with files whose size modulo 253 is 175. And I don't know why yet.

Wow, that is pretty obscure bug :O You are a pretty pro bug finder :D

It took me a bit more than an hour, as noted in my previous post

I almost immediately had the (correct) intuitions (both logical consequences, to me, of facts I know) that:

• the problem is related to the file's size, not its contents. It's mainly because I know that the file's size is not stored into the file itself on Nspires (it is on TI-68k/AMS) and that almost arbitrary binary files can be successfully sent to the calculator;
  
• only a small subset of the possible sizes exhibits the problem. This is because, AFAICT, there have been no prior reports of "this file will not transfer to the calculator with TILP" - it would seem logical to have had more such reports over the years if many files were affected.

The first intuition was shortly confirmed by testing (sending several random files to the calculator and sending the file after slight modifications, see edit 1 and 2).
It took longer for the second intuition to be confirmed by testing as well. I didn't generate files of all sizes and try to send them, I just tried - and happened to succeed, but I would have failed if the problem had a different periodicity, so in a way, I was lucky - to find the pattern by making files that are about 1, and then 2, 254-byte (1 control + 253 data bytes) packets shorter. Since the problem seemed to repeat itself with a periodicity of 153, I computed 32812 mod 253, yielding 175. That's what I described in edits 3 and 4.


EDIT 1: fiddling with the maximum packet size (e.g. from 254 to 253) shows that the problem is with 176-byte (1 control + 175 data) packets. I'm now probably going to generate all sizes from 0 to, say, 768 bytes, and transfer all these files to the calculator.

EDIT 2: OK, so there's a problem with file sizes 47 (0x2F), 111 (0x6F), 175 (0xAF), 239 (0xEF), 300 (47 + 253), 364 (111 + 253), 428 (175 + 253), 492 (239 + 253), 553 (47 + 2*253). That looks like a pretty clear pattern to me.
TODO: see what packets transit between TINCLS and the Nspire when performing the same transfers.

Cross posted from cemetech.

OMFG!!! Lionel Debroux it is time for all Windows users of TiLP to rejoice for 2 reasons.

1)libusb-win32 is now WHQL signed so we are now 64bit safe. We just need to update the version of libusb-win32 we package to include this.

2)The filter driver does indeed allow our driver and Ti-Connect to be installed at the same time with no uninstalling of drivers. All that is required is that one add all the device to the filter list and it "Just Works". I would suggest we add an option to the installer to use this route in place of the normal libusb driver.

All this info can be found on the libusb-win32 wiki.

Indeed, it's great news that there is now a signed version of libusb-win32

From what I can gather from the libusb-win32 website, libusb-win32 is still tracking the libusb 0.1.x API... That is going to help, because, as you know, libusb 1.x is not yet supported at all by libticables (though it needs to be at some point), not even through the compatibility layer for libusb 0.1.x (since libticables is using implementation-dependent details of the internal libusb structures, to access asynchronous functions that were not directly usable).

In the upgrade process, we "just" need to take care of retaining the little idiosyncrasies made necessary by TI's buggy devices (e.g. a different reset sequence for the Nspire)...