I’m pleased to announce the availability of Luna v0.2!

This version adds support for arbitrary TI-Nspire “problems” conversion from XML format to TI-Nspire TNS documents compatible with OS 3.0.2 and above. This could not easily be done on the latest OS versions before, because TI took the sad decision to protect its OS from interoperability with third-party user tools.

Suppose you now want to build a computer tool that generates TI-Nspire documents with Notepad widgets.

1) Build the problem template: on nspire_emu, create a new document with a Notepad widget (“Add notes”). Put a debugger breakpoint to export the document in XML form, before it is compressed and encrypted: on a non-CAS OS 3.0.1, you would use something like:
k 10032AA0 +x
c
[save the document here]
w problem.xml r1 400
[repeat if the problem is bigger than 1024 bytes to get each problem chunk]

Some alternative methods such as copying from TI-Nspire Software and exporting the content with Levak’s clipboard dumper may also be used instead, or as adriweb suggests for Mac users the “Clipboard Viewer” available with XCode in /developer/Applications/Utilities/.

You will get an XML document that looks like (the Notepad only contains a “Hello world” here, the TI-Nspire XML format is indeed quite verbose):

<?xml version="1.0" encoding="UTF-8" ?>
<prob xmlns="urn:TI.Problem" ver="1.0" pbname="">
<sym></sym><card clay="0" h1="10000" h2="10000" w1="10000" w2="10000"><isDummyCard>0</isDummyCard><flag>0</flag>
<wdgt xmlns:np="urn:TI.Notepad" type="TI.Notepad" ver="2.0"><np:mFlags>1024</np:mFlags><np:value>3</np:value>
<np:fmtxt>&lt;r2dtotree&gt;&lt;node name=&quot;1doc&quot;&gt;&lt;node name=&quot;1para&quot;&gt;&lt;node name=&quot;1rtline&quot;&gt;&lt;leaf name=&quot;1word&quot;&gt;hello &lt;/leaf&gt;&lt;leaf name=&quot;1word&quot;&gt;world&lt;cursor index=&quot;0&quot;/&gt;&lt;/leaf&gt;&lt;/node&gt;&lt;/node&gt;&lt;/node&gt;&lt;/r2dtotree&gt;</np:fmtxt></wdgt></card></prob>

2) Write your problem generator based on this template

3) Integrate Luna with your generator:
luna problem.xml outdoc.tns

Quite easy, isn’t it? :)

[update 2011/09/21] Levak tells me his Make3D program which features a Lua plugin system can now be built with Luna and its XML converter for compatibility with OS 3.0.2 and later! Minor encoding issues had to be worked around, we’re looking further into them.

Luna is the first third-party Lua script converter for TI-Nspire compatible with OS 3.0.2. It defeats the useless compression and encryption layers described in earlier posts.

Long-time TI-Nspire users, you now won’t need to pay for a Computer Software licence to code in Lua.

Developers, you won’t click and click and click anymore to convert/test/run your programs as you have to with the official kit.

Linux users, here is a portable tool.

Hackers, this can be a good base to build (or rewrite) third-party TI-Nspire document generators.

Enthusiasts, support for C and ARM on OS 3.x might not be so far…

I like this sound of openness and happiness, don’t you too?

I finally could find a couple of hours to go further on the converter.

As you remember the OS 3.x TNS file format has 4 layers: 1) XML compression, 2) zlib compression, 3) triple-DES encryption and 4) zip wrapper. 4) and 3) are now supported by the converter, but it fails miserably on the inflate() call for 2) with a Z_DATA_ERROR… The deflated 512-byte block to inflate seems OK, and can be inflated on the computer side without problem.

What could be wrong?

[edit 2011/08/01] 2) (zlib compression) now passes! the zlib stream needs to be produced with a negative windowBits parameter, to avoid emitting a zlib header.

And now probably the last step: 1) (the XML compression) fails at the 13th 512-byte block of the Lua sample program I use, in the TNS decryption loop…

So a TNS file entry compressed with the unknown “D” method is:

1. XML-compressed by the OS with a custom binary XML method
2. deflated with zlib
3. Encrypted

I was curious about 1) and 3).

I first checked that XML-compressing a Lua script from a skeleton (similarly to what the current third-party Lua converters for OS 3.0.1 do) is quite easy without needing to implemented the patented algorithm, thus avoiding any legal issues. This is good news.

I also had a closer look at the encryption algorithm. It is actually an OpenSSL-based Triple-DES encryption in ECB mode (thanks Google Code Search for making ARM code so much clearer). The 3 keys are probably embedded in the OS although I didn’t bother to look where exactly. Computer-side encryption tests confirm that the 3 keys I found are the good ones.

Integrating this into to a new Lua converter compatible with OS 3.0.2  should now be easy :)