As you might have noticed, when you connect your HP Prime to the computer then open the Connectivity Kit software, it takes about 10 minutes before the software has finished displaying the entire calculator content. It is not as bad when you have a small amount of programs (takes around 30 seconds), but when you have about 30 KB of them, 10 minutes is what it takes (with some chances of the connection dying in the meantime), meaning that if you create a game that is 500 KB large, you'll most likely have to wait several hours before the software finally detects it, pretty much rendering transfer of any large files (or small files from an overcrowded calc) impossible.

In addition to that, the connectivity kit software itself cannot transfer files. The only way is to open the program code in the software, copy its entire content, then create a new program on the calculator and paste the code in there. Once done, you hit save, but the issue is that it takes about 30 seconds per kilobytes before the updated program finally appears on the calc and there is nothing telling you it's actually sending at all!

Also, in the connectivity kit, you cannot transfer anything to the calc until the software is done 100% reading the calc content. If you want to backup often, you better wipe out your entire calc content and only keep what you're working on.

The alternate way is to use the HP Prime emulator, which sends files directly to the calc. However, it comes with the same problem about slow file transfers and 90% of the time the emulator will stop detecting the calc after one minute or so, meaning you have to disconnect and reconnect it over and over and making the transfer of any larger file impossible.


Since it is unclear yet if this software will be updated anytime soon and work better, I wonder if it would be best to have third-party tools, such as a HPLP software (in reference to the TILP name)? Anyway I saw this post on TI-Planet at http://tiplanet.org/forum/viewtopic.php?p=150590#p150689 and I think that Lionel and Critor might have started doing so, so I thought I would bring this up in case anyone with the knowledge or time to do it would be willing to help. Here is the current Github project URL (for now): https://github.com/debrouxl/hpcomm

I wonder if this software would manage to get around the long delays for file transfers too?

Cool to hear. Apparently Tim didn't have this slowness issue I mentionned above, so I'll send him a program that fails to send at a reasonable speed. It was just a program that scrolled through the entire Super Sonic Ball sprite sheet and it was over 10 KB large, but I had a different version with updated sprites that was much larger (around 18-28 KB IIRC). I hope it's not computer compatibility issues >.< (I use Windows 7 64 bits and a first gen i7 computer from 2010).

How large were your files btw?

Also what is the send to class function?

Oh right, that part. I wonder, though... what is the speed difference between that and just sending normally via the emulator or other methods?

Strange, I had no problem with it. Key detection was weird but that's due to its programming.

EDIT: Btw where can I find the calc folders in the connectivity kit? I use Windows 7 and parts of your path isn't visible in the screenshot.


EDIT: By the way, I just ran another test and to read through 86 KB of memory content, the connectivity kit took me about 8 minutes (before I could finally update any program from there). Once done, I tried to send the Super Sonic Ball update that is 46 KB large and it took about 1 minute. I think the long delays I got might have been due to the connectivity kit not having been done reading my calc yet, but even 1 minute is still rather slow when you know that many games will reach hundreds of KB of memory.

I for one am looking forward to any improvements to the software. Trying to create programs on this thing right now are a pain.

Gratitude to anyone/everyone working on doing so.

Yesterday evening, critor confirmed that my latest changes produce a directly usable PNG file. The colors are still messed up, but I'm outputting verbatim the data part of the packets produced by the calculator (or so I think, at least ).

Screenshotting and backup are supposed to be implemented reliably, besides the strange colors in the screenshots (but I'm not mangling the output). Printing logging output to a file instead of the horribly Windows terminal tremendously helps for reliability...
I'm not aware critor transferred back a file created by test_hpcalcs to the calculator using the HP Connectivity Kit.

What's holding further implementation of libhpcalcs / test_hpcalcs at this point, is the integrity checking value: 16-bit value in the header of packets, which varies with the variable name and the variable contents. I can't find how it is computed, even with a brute-forcing program, which I've posted at http://tiplanet.org/forum/viewtopic.php?p=151303#p151303 : the more eyes and brains, the better !
There seem to be such integrity checking values in the packets used for sending and receiving individual files, so I assume that these operations cannot work until we get this integrity-checking computation right.