Here's how I made the .tns file:

• Create a blank document
• Create a Problem1.xml file, containing the following (without any line breaks, except in the script itself):
  <?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:sc="urn:TI.ScriptApp" type="TI.ScriptApp" ver="1.0"><sc:mFlags>0</sc:mFlags><sc:value>-1</sc:value><sc:script>Lua script goes here (with appropriate character entities replacing the five characters < > " ' &)</sc:script></wdgt></card></prob>
• Use 7-zip to create a zip file containing Problem1.xml
• Concatenate the beginning of the blank document, up to the end of Document.xml (at offset 0x170), with the zip file. (OS 3.0 requires Document.xml to be encrypted, but thankfully Problem*.xml can still be unencrypted.)

First Lua game on the TI-Nspire

The SMRPG cartridge doesn't work in fake SNESes because of they lack the CIC lockout chip.

A permanent root exploit for Nucleus RTOS? That would rock.

The only way you can call Nucleus functions is if you're already running code, so this doesn't make much sense.

Anybody analysing the new downgrade protection?

It's not in the TNC/TNO header anymore...


Hard-coded in the OS?

They probably did it this way to avoid the following scenario:

• person installs OS 3.0 on his ancient clickpad TI-Nspire made in 2007 (which still has boot2 1.1.8981)
• during installation, downgrade protection from TNC/TNO header written to bootdata
• OS 3.0 won't boot because of the bug in old boot2 versions that prevent them from launching large OSes
• person reads about bug, deletes OS 3.0 with maintenance menu, tries to install OS 1.7, but...
• OS 1.7 won't install because of downgrade protection
• TI forced to fix calc at their own expense to avoid lawsuit

I suppose in theory if you could replace the flash chip with a larger one, then you could use the space beyond the filesystem (current boot2's and OSes have hard-coded the filesystem area to end at 32MB, although this may change when OS 3.0 comes out because the CX will have a 128MB flash chip). I don't think there are many of us who could do that, though :p

Out of curiosity, has anyone taken a look at the filesystem formats yet?

I looked into it a little bit a while back.

The first thing you need to know is that there are two layers involved. FlashFX Pro does bad block management and wear leveling, essentially presenting a "hard-disk" abstraction to the code above it. (You can repeatedly tell FlashFX Pro to write to the same page, but it will actually cycle through many different pages, to avoid wearing out the flash with repeated erase/program cycles; it remembers which logical page corresponds to which physical page so you will always get the right data back on a read.) On top of FlashFX Pro is Reliance, the actual filesystem.

FlashFX Pro divides the physical space into 937 "units" of 64 pages (0x8000 bytes) each, and the logical space into 59 "regions" of 976 pages (0x7A000 bytes) each. Each unit has a header page (I don't know the exact meaning of all these fields; the names are from some code in the command shell)

Bytes 00-0F: signature (CC DD "DL_FS4.00" FF FF FF FF FF)
Bytes 10-13: "clientAddress" (logical address of which region this unit is holding data for; always a multiple of 0x7A000)
Bytes 14-17: "eraseCount"
Bytes 18-1B: "lnuTag"
Bytes 1C-1F: "ulSequenceNumber"
Bytes 20-23: "serialNumber"
Bytes 24-27: "lnuTotal"
Bytes 28-2B: "numSpareUnits"
Bytes 2C-2D: "blockSize"
Bytes 2E-2F: "lnuPerRegion"
Bytes 30-31: "partitionStartUnit"
Bytes 32-33: "unitTotalBlocks"
Bytes 34-35: "unitClientBlocks"
Bytes 36-37: "unitDataBlocks"
Bytes 38-39: "checksum"

The extra 16 bytes that the flash chip has for every page are also used to hold information:
Bytes 0-1: tells which logical page this is within the region; ranges from 0x4000 to 0x43CF. (All unit header pages have this field set to 0x48E2.) Sometimes the same page of the same region will appear multiple times in different units; I don't know yet how to tell which one is the latest version of the page.
Byte 2: ones-complement of byte 0 XOR byte 1
Byte 3: error-correcting Hamming code of bytes 0-2
Bytes 4-7: seems to always be FF FF FF 0F for used pages, FF FF FF FF for unused
Bytes 8-B: error-correcting code of second half of page data
Bytes C-F: error-correcting code of first half of page data

Reliance seems to be a fairly conventional filesystem, in terms of data layout. Here's the inode structure, used to describe a file or directory:
Bytes 00-03: "INOD"
Bytes 04-07: inode number
Bytes 08-0B: size of data
Bytes 10-17: some kind of timestamp (in microseconds since 1970)
Bytes 18-1F: some kind of timestamp (in microseconds since 1970)
Bytes 20-27: some kind of timestamp (in microseconds since 1970)
Bytes 28-2B: flags
Bytes 2C-3F: always zero?
Bytes 40+: data - format depends on low bits of flags:
  If 0: contains data directly (can be up to 448 bytes)
  If 1: contains pointers to data pages (up to 56 kB)
  If 2: contains pointers to "INDI" (indirect) pages containing pointers to data pages (up to 6272 kB)
  If 3: contains pointers to "DBLI" (double indirect) pages containing pointers to "INDI" pages (up to 686 MB)

You find an inode by looking it up in inode 1's data (inode 1 is a table of inode pointers). Not sure how you find inode 1, though :p

Edit:

The best thing would be to have an image with the linux rootfs, and just point the kernel to the raw location of the file on the nand. This way you would not need to know how the filesystem works.

The problem with this is the filesystem won't keep your image file contiguous.

Hexadecimal (I'm not aware of anyone who programs in Binary) is often regarded as impossibly complex and unwieldy to program in. This is, at least in my experience, no the case.

It depends on the program. If you have a program that is just a single chain of actions, each of which is individually simple, then you only ever need short relative jumps ("jr" instructions on the Z80), and programming in hex will work just fine. But large programs usually end up frequently needing to call subroutines or jump to far away code. Keeping track of addresses becomes a big problem - if you add just a single byte to one piece of code, everything after it now has its address shifted by 1. Now you have to go through the whole program and adjust all the calls/jumps... a very tedious (and error-prone!) process.
Of course, an alternative would be to never change the size of any code once it's written, and just 'patch' it to jump somewhere else, do something, and jump back. But this would turn your program into a bloated and convoluted mess after a while.

The big benefit that an assembler gives the programmer isn't instruction mnemonics, it's labels.