Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Lionel Debroux

Pages: [1]
HP Prime / libhpcalcs: a toolkit for communicating with Prime calcs...
« on: November 09, 2013, 04:20:26 pm »
See the end of the post for download links.

Over the past few weeks, as mentioned at and , I've been working on a toolkit for communicating with HP Prime calculators, strongly inspired by libti* for TI calculators, and unsurprisingly dubbed libhpcalcs. It can be downloaded from .
Thanks to critor's USB dumps and tests (EDIT: and later, other persons' tests), we believe the code now works well enough for being beta-tested used by a wider public (on Windows, Linux and MacOS X) :)
While neither critor, nor I, believe that anything can make a significant dent into TI's market share because TI is too entrenched and has lobbying power, we're nevertheless trying to do something with the Prime... as it's clear that if nobody bothers, the Prime won't stand a chance to get widely used (chicken-and-egg problem).

"Toolkit for communicating with HP calculators" means that it's a library backend for people to build GUIs on top of it, but libhpcalcs itself is a GUI-less library, and its terminal-based test program is currently the only UI for using libhpcalcs...

Excerpt from the README about the library's current capabilities:
The code base does:
* support communication with a single Prime calculator connected to the computer. The communication is known to work with the "SDKV0.30" firmware version from mid-August 2013, but might not work with other older or newer versions, if HP performs backwards-incompatible changes in the protocol (like TI does);
* implement six operations (without _known_ bugs): ready check, get calculator information, receive screenshot, send file, receive file, receive backup, set date and time;
* provide a terminal-based UI: the test program "test_hpcalcs".

The code base doesn't:
* perform color conversion on PNG screenshots (libhpcalcs should depend on libpng to uncompress the files, and recompress them after mangling);
* provide a way to select one of multiple HP calculators (probing USB devices);
* provide a user-friendly GUI for the above, but a GUI can definitely build upon the library easily enough;
* implement _proper_ conversion from UTF-16 LE to other charsets on its own: that's a task for libicu, Qt or other libraries;

What's next ?
* first of all, making sure that people are interested in the work in the first place. I'm clearly not going to keep spending most of my free time (as I did over the past week) on something people do not find useful ! [EDIT a couple weeks later: seems that some people are interested :)]
* fixing bugs which are bound to be reported, none are known right now but there certainly are some :)
* implementing several extra features from the TODO list embedded into the README, starting with probing devices;
* implementing a GUI for the program (with Qt, which has become the main choice for a portable, good-looking, fast UI toolkit and software abstraction layer)... but I don't plan on doing it by myself, although I'll obviously gladly support anyone trying to do so.
* implementing 39gII support ?
* certainly more... again, iff people are interested.

Go forth and test, thanks in advance ;)

Development source code: (master branch is stable, master2 contains changes for testing, which may be rewritten before integration to master).
Ready-made install script: . Unless your distro packages hidapi (Debian and derivatives do not), you'll have to compile it yourself (autotools-based program, so configure && make && sudo make install).
Latest Windows binaries + source tarball: .

Also, I'm looking for 39gII users who can tolerate command-line tools, for providing me USB dumps (usbpcap) from their Windows computers when running the HP Connectivity Kit, the way critor did for the Prime.

[latest EDIT: 2013/11/16]

Other Calculators / Several fun facts about the Nspire family...
« on: June 07, 2012, 03:36:00 am »

Several fun events have occurred over the past few months in the Nspire family and its predecessor, the Nspire CAS+.
These events bear some potential and promise, and they are definitely worth explaining to a wider audience :)

1) news from the CAS+ series.

The Nspire CAS+ prototype series was made in a year before the regular Nspire series, in 2006. It's completely incompatible with regular Nspires. CAS+ handhelds were never supposed to be sold (after this series was scrapped, that is); however, dozens, probably hundreds, of items slipped from classrooms or teachers into the wild.
Their terrible "Nspire CAS+" name has made them a pleague on the aftermarket since then, because they are easily mistaken by unsuspecting buyers as more capable than the "Nspire CAS" calculators - while they are just old, non-upgradeable prototypes, with the lowest OS capabilities found on the Nspire series - that's not much !
And it's trivial to brick them, by triggering the "OS upgrade" procedure, which erases the OS. Scammed customers are even more unhappy after that...

On the one side, TI has not (yet ?) fixed the persistent problem of the CAS+ series on the marketplace; on the other side, several well-known members of the open development community have recently spent quite a bit of time on helping scammed customers, and managed to dump multiple OS versions suitable for the CAS+ series, and reconstruct OS images which make it possible to unbrick calculators (confirmed by fixing real CAS+ bricks) :)
As usual, the fact is that the open development community cares more about fellow users than TI does; but it's not too late for TI to do their part of the job...

It's a matter of time and motivation before native code runs on the CAS+ (making it possible to dump the boot1 and boot2), and possibly an emulator is made for it.
A noteworthy bit: we believe that it's possible to write to the boot1, i.e. to subvert the root trust of the calculator. In layman tems, it means that the CAS+ ought to be able to host permanent installs of arbitrary OS.

More information on the CAS+ breakthrough:

2) news from the Clickpad prototypes

Like the CAS+ prototypes, '2007 Clickpad prototypes slipped into the wild. Unlike the CAS+ prototypes, the Clickpad prototypes are fully compatible with production models. There are two known differences between prototypes and production models:
    * one track on the PCB (more on that later);
    * the RSA signing/validation keys are different, so prototypes won't accept production boot2 and OS.
Though easy to dump (they reply politely when the linking software asks them to send "../phoenix/install/TI-Nspire.tnc" - a schoolbook directory traversal vulnerability :D), Clickpad prototypes are as hard to upgrade as CAS+ prototypes, because TI doesn't provide OS builds suitable for them (it's just a matter of signing them with a different key !).
Clickpad prototypes are locked onto special OS builds; only the severely outdated 1.1.x and 1.2.x prototype versions are known to us, so again, there's potential for scamming customers.

Well, actually, they _used to be_ locked onto old OS versions: the boot1 of Clickpad prototypes is writable as well. It is therefore possible to permanently install production boot2 and OS, and thereby upgrade them to production status :)
critor made a detailed tutorial on this topic:

But upgrading prototype Clickpads to production status is just a special case of permanently installing arbitrary boot1, boot2 and OS on the calculator. Yes, even the CAS OS on the CAS-capable model sold as non-CAS, and/or an OS which doesn't obey PTT restrictions, as special, and inevitable, cases of the users' inalienable rights of running whatever software they see fit on the computing platforms they own.

Clickpad prototypes can trivially be smuggled into exams: not only untrained exam personnel is unlikely to notice the difference (even though most prototypes models have a "TI-XXXXXXXXXX" mark on the front, and "PROTOTYPE NOT FOR SALE" + non-standard serial numbers on the back), but anyway, the hardware of a prototype Clickpad can easily be put into the casing of a production Clickpad, effectively hiding prototypes.
It would be harder to smuggle CAS+ items into exams unnoticed, because those don't look like regular Clickpads; that said, I bet that untrained exam personnel could be fooled.

3) news from the production Clickpads

Unlike that of Clickpad prototypes, the boot1 of production Clickpads is not directly writable. It's because the PCB track which makes it possible to act on the WE# pin of the SST39WF400A NOR Flash chip, visible on the prototype PCB, does not exist on the production PCB.

But chances are that it doesn't matter: adding an equivalent wire between the main R/Wbar line of the Nspire's bus (found e.g. onto the appropriate pin of the Zevio processor, and onto other places of the PCB) and the WE# pin, thereby making the boot1 writable, may work. Then, people can proceed to subvert the root trust of the calculator, so as to be able to permanently install arbitrary boot2 and OS, and exercise their full user rights on the platform :)

4) news from the Touchpads and Lab Cradles

Touchpad Nspires do not have an external NOR Flash chip for the boot1, so we assume that the boot1 is embedded into the Zevio processor. That said, there has to be a way to program it into the processor, as part of the calculator production process: either very early on, by the manufacturer, during the production of the Zevio chip, or later by the
user of the Zevio chip (TI).

A related fact is that while Lab Cradles use a Zevio chip with the same name as Touchpad Nspires, they contain an external EN39SL800 NOR Flash chip. See . For obvious cost reasons, few manufacturers add unnecessary hardware / PCB tracks on their boards... so the presence of an external NOR Flash
chip means that the Lab Cradles' Zevio supports an external NOR Flash.

Grafting an external NOR Flash chip onto Touchpad calculators, if at all possible, is expected to be highly impractical, as it requires significant equipment and expertise.

5) news from Clickpads, Touchpads, CX (and undoubtedly CM).

Ndless 3.1 can be installed on a calculator in a resident way; one of the capabilities of Ndless 3.1 is to launch programs at OS startup, before most of the OS's code runs.
Like the rest of developments mentioned here, it's perfectly legal, and besides, it fulfills interesting purposes, such as hot-fixing TI's bugs, e.g. the removal of the useful serial port output in Lua, reverted by a team work of open development community members ( and ).

Obviously, Ndless doesn't care about not working at all PTT mode; if it did, checks for the PTT mode would be easily removed, and the modified versions would be easily distributed, so it's completely pointless to add such checks.
As a result:
* since OSLauncher for Ndless 3.1 works (more or less) in startup mode ( ), it's harder to disable than the first iteration (for Ndless 1.7/2.0), last year, was;
* since the PTT implementation itself proves to be fairy dust, it's trivially subverted. See for instance .

Unsurprisingly, the Nspire's so-called protection is just as much of a laughingstock as the 84+'s protection. It is fundamentally impossible to make a foolproof protection, and the lower the cost and complexity, the worse the protection.
Like on the 84+, it's _technically_ possible to defeat the PTT and to install a CAS-capable OS on some Nspire models. But these possibilities didn't get the 84+ banned from the ACT and IB, so there's no reason why the Nspire series should be banned.
That said, since the incompetents who regulate standardized tests freaked about OSLauncher in 2011, though it was clearly perfectly harmless (because its effect went away by just rebooting into PTT mode), who knows what they would do this time...

You might think that this is an avalanche, but on the contrary, the truth is that programmers and users have barely scratched the surface :)
When TI's repeated egregious violations of our basic user rights to do whatever we want with the hardware we own have _really_ angered people, the Nspire series will go the way of the PS3, and it won't be pretty.
As I told them months ago (I spent the equivalent of two full-time days to write stuff for them - as expected, I failed to convince them, but at least, I'll have tried), all of that could be avoided with TI Education showing respect to its paying customers, who make that division rich enough...


Yesterday evening, NeoCrisis reported, on TI-Planet, about his attempts at using a NDS rechargeable battery for powering a Nspire Touchpad calculator, instead of an official (and more expensive) battery.
Short story: it seems that it can work :)
More information, in French, at . Note that he hasn't tested every possible situation yet, and the slightly thicker form factor of the NDS's battery seems to require using a bit of mechanical force to plug the cover back in.

The article is pretty detailed, and is as a result lengthy. I guess he hasn't had time to translate it completely yet (and I don't have it either right now), but I think that it will be translated soon. The article contains links to French-speaking sites for buying such batteries.

Needless to say, reproducing his experiments is at your own risk ;)

EDIT: fixed typo, and Neocrisis -> NeoCrisis.

Site Feedback and Questions / E-mail notifications gone...
« on: July 24, 2011, 02:06:53 pm »

I use e-mail notifications a lot, because this forum is very high volume (which is, in itself, a good thing !). And after [this morning, in my timezone] 's server reboot, e-mail notifications don't work anymore... People using the notifications are going to miss lots of replies :(

TIA for fixing the server ;)

Lua / Third-party ports of Lua to TI calculators...
« on: June 28, 2011, 08:29:45 am »
* for the Nspire platform, let's not forget davyg's effort, , because it would let us some independence wrt. what TI feels like giving us. Remember, the new 84+(SE) boot code is further proof that they're trying more actively than ever to lock things down.

* for the TI-68k platform: recently, on yAronet, an experimental port of an older version of Lua (5.0.2) to the TI-68k was mentioned.
It's a "kernel"-based program (lua.89z), using three "kernel"-based libraries to overcome the 64 KB size limit: "liblua" (core), "lualib" (some library functions), and "lamslib" (AMS-specific library, which currently contains Lua wrappers for getkey, ngetchx, clrscr, DrawPix, ScrRectFill and DrawStr).

After shuffling files around (lualib/* -> src/lib/, core/* -> src/), the diff against upstream Lua 5.0.2 comes up rather small: . It's likely that it could be ported forward to newer versions of Lua without too much hassle :)
Several io.* functions and a couple math functions haven't been implemented, there's no support for stdin / stdout / stderr on AMS / TIGCCLIB / GCC4TILIB, and the source ought to be modified for using the strtod built in AMS (I integrated strtod into GCC4TI last week-end, "it never got done" in TIGCC since 2003 or even 2002) but it's nevertheless bound to be usable for a number of classes of programs - especially if someone spends a bit of time expanding lamslib :)

And there's another way to overcome the size limit: making the Lua interpreter and library a FlashApp. For that purpose, we don't even have to withstand TI's horrible toolchain from end to end: GTC is known to be compiled largely with TIGCC / GCC4TI, and linked with TIFS.

* for the TI-Z80 platform: well, compiling the Lua interpreter yields a binary large enough it wouldn't be great fun to deal with paginated memory...

Other / Special offer for Arduino Uno at Lextronic...
« on: February 12, 2011, 11:19:39 am »
I saw that the well-known French reseller "Lextronic", is currently making special offers with the Arduino Uno board (one of the models which can be used for a CALCnet - globalCALCnet bridge, see ):

There are two additional gifts, as long as supplies last:
* several resistors, capacitors, LEDs, and other things;
* a VGA output module (for a strange resolution) controlled by a serial link.

That said, 1) the supplies may have already been exhausted since the offer began yesterday, and 2) they ship in France with shipment fees of 8€, or in Europe with shipment fees of 21€...

Yesterday morning (European time), on #ti, several of us discussed about the possibility of opening new subdomains, for pointing to external, significant projects (and possibly storing some data).
There are multiple goals, starting with increasing the visibility of some significant projects even more, and reinforcing the role of as a link between programmers, users and projects :)

To summarize and provide a starting point for a wider discussion, before the result of the discussion becomes reality (should it be decided to go ahead), I have created a more detailed topic on UTI, .
To reduce the necessity to cross-post across forums, it would be best to post only on UTI, but you can post here too.

TI 68K / TIOSMOD: a computer-based patcher for TI-68k OS (for now)...
« on: August 13, 2010, 03:14:07 pm »
Over the past few months, in an intermittent manner, I've started scratching an old itch of mine: patching TI's OS for TI-68k in an automated way, in order to optimize several sore performance spots that have bugged me for at least six years... and while at it, killing the silly protections laid out by TI, and why not fixing their bugs as well.
I discussed about the idea and program privately with several persons, one of whom (BrandonW) suggested to go up one level in genericity: split the patcher application and the patches themselves (written in a scripting-type language). The direction is clearly good, but I haven't reached such levels of abstraction yet, although I have tried to make a set of primitive functions generic enough to be usable for both TI-68k OS and TI-Z80 OS :)

So here's a patcher, which kills several protections, optimizes a bit several sore performance spots of the official TI-68k OS, fixes some bugs - and shrinks two versions so as to provide users 64 KB of additional archive memory (which older versions used to provide).
The latest version can currently be downloaded from .

As noted above, the program is by no means a finished product, it's a seed for going further. The todo/wish list proves it. There's a lot that we could collectively do, in order to gain further power on calculator lines that are mostly, or totally, abandoned by the manufacturer - and help our fellow users :)
Contributions are more than welcome. To that effect, I have opened a Git repository on Github,
Enjoy ;)

Older versions, for historical purposes: , , , , , , , ,

[EDIT 20100822: posting a new version.]
[EDITs 20100914: posting two new versions.]
[EDITs 20100916: adding the Github repository information; posting a new version.]
[EDITs 20100922, 20100925, 20101017, 20101024: posting a new version.]

Quote from: Wayne Pace (from tinspire Google Group)
As I say, I do not have a saved list, but from memory:
There seems to be an issue with the (generalized) eigenvalue, eigenvector routines.  Try the matrix [0,1;-1,-1]. I think you will find that if the matrix is multiplied by the first returned eigenvector and the result is subtracted from the product of the first returned eigenvalue and the first eigenvector, then the result is not the zero matrix as would be expected.  Similarly for the second returned eigenvalue and the second returned eigenvector.  By interchanging the order of the returned eigenvalues and performing the same operation, you will get the correct result.  In other words, the order of the returned eigenvalues does not match the order of the returned eigenvectors.  This is not too hard to figure out for a 2x2 matrix, but I did not want to try to figure out how the order of the returned eigenvalues matches to the order of the returned eigenvectors for say an arbitrary 5x5 matrix.

There seems to be an issue with the SVD routine.  Try the matrix [1,0,0,0,2;0,0,3,0,0;0,0,0,0,0;0,4,0,0,0].  Again, I don't remember what happened the first time, but with this latest installation, I get one column of the UU matrix as "undefined".

There seems to be an issue with the Divisors routine in number theory.  With this new installation, Divisors(147) returns {1,3,7,21,49,343,147}.  Note the extra element in the list.  The documentation is also incorrect.

There seems to be an issue with the Jordan canonical form routine.  Try the matrix [3,-1,1;2,0,1;1,-1,2]. I do not remember what happened when I first encountered this problem, but with this latest installation, I receive an invalid list error message.
(cannot reproduce, it was probably a different input)

That's all I can remember for now.  Maybe I can remember some others when I have a chance to think back a little.

General Calculator Help / TIEmu: beta-testing...
« on: May 17, 2010, 02:50:43 pm »
Hello everybody :)

I have uploaded at a pre-version of TIEmu 3.04 no-GDB, for beta-testing purposes :)
(*nix users can try, start by looking inside the script)

Since TIEmu 3.03, visible changes are fixes in the memory maps and I/O definitions, and fixes in the disassembler. Other changes, more visible to *nix users, include code updates not to use functions deprecated in recent GTK+ versions (2.20). Some updates to internal documentation, too. To sum up things, not much so far.

Before TIEmu 3.04 release, Thibault Duponchelle (a.k.a Contra / azerti, also working on TiLem-NG) and I are working to make TIEmu at least not crash anymore when loading on a 64-bit computer savestates created on a 32-bit computer, and vice-versa. With the ongoing switch to 64-bit computers, we'd better fix TIEmu somewhat before this known bug bites too many users :)
Note that transparently handling savestates created by buggy TIEmu versions is significantly harder than transparently handling images created by buggy TIEmu versions (which I contributed in 2009 to TIEmu, before becoming a (co-)maintainer, and is already available in TIEmu 3.03).

NOTE: thanks to updates of the shared libti* DLLs, as a side effect of installing this setup program for a beta TIEmu _after_ installing the beta TILP version featuring Jonimus' UI improvements (see e.g. ), , you can get Nspire OS 2.x support in TILP, which I added last week-end by integrating (with minor changes) a patch contributed on the SF bug tracker.

The GDB-enabled version will follow later - I think it would be best to try bringing the huge (more than 120 KB !) NSIS definitions to a more manageable state first. NSIS does support wildcards, but there's no single wildcard in the TIEmu+GDB NSIS definitions created by Kevin, weird...

Thanks in advance for testing ;)

Other Calc-Related Projects and Ideas / TILP: beta-testing...
« on: January 22, 2010, 01:30:22 pm »
I have uploaded at a pre-version (for Windows, obviously :D) of TILP II 1.14, for beta-testing :)
(*nix users can try , start by looking inside the script)
Even if I'm trying to get myself the necessary infrastructure for being a decent (co-)maintainer (bought a 89T, a 83+SE and a SilverLink), it's necessary to perform wider and deeper testing than just what I did on my Vista x86 and Seven x64 VMs ;)
In particular, I can see driver trouble on Seven x64 (complains about unsigned drivers) but not under Vista x86. I can also see that unless the UAC is completely disabled (baaaaad !), Seven forbids TILP to write tilp.ini => need to improve this (by changing the location, probably).

Since TILP II 1.13, visible changes are TI-68k bugfixes (especially for PedroM), and important bugfixes for TI-Z80 (TI-Connect is now much happier with files and groups created by TILP). TILP keeps supporting, in a transparent way, the incorrect groups created by previous versions. I think I fixed a build/packaging problem that makes TILP II 1.13 not work for many users.

This test version was compiled with MSVC 2008 and GTK+ 2.12.9 (such was the result of a multi-forum poll one year ago: 9x/ME/NT4 support is no longer guaranteed).
Therefore, you have to install the VC++ 2008 Redistributable Package ( ) if you don't have it yet. I hope to find a working MSVC 6, so as to remove that dependency.

A small limitation in this test version: no French locale. Not that most of those who read this board care, though.

Thanks in advance ;)

EDIT in 2021: updated the link to the *nix install script.

Pages: [1]