I guess we need more experimental data, to try and understand what's happening. At least:
* CX CAS calculator running the CAS OS normally (not through nLaunch), without Ndless;
* CX CAS calculator running the CAS OS through nLaunch, with Ndless;
* CX CAS calculator running the CAS OS normally, with Ndless;
* CX CAS calculator running the non-CAS OS through nLaunch, without Ndless;
* CX CAS calculator running the non-CAS OS through nLaunch, with Ndless.

At least, as long as the OS is not patched specifically for interferring with PTT (normal PTT LED activity, but unrestricted functionality) by either a modified copy of nLaunch, or a Ndless startup program, the latter being easier.

Indeed, the speed of most emulators is not accurate at all. Benchmarking on real hardware was the only way to achieve fairness

You can send multiple versions (in fact, some people have), we'll keep the latest one

A bit more than five hours left... don't forget to send the files in

The officially announced hardware specs are far below the specs of even '2007 Nspire Clickpad series, let alone the specs of the Nspire CX or HP Prime (which has a touch screen as well)... The fx-CP400's specs aren't even a massive improvement over the Prizm's specs.

EDIT: http://www.casio.com/products/Calculators_&_Dictionaries/Graphing/ClassPad%20fx-CP400
http://www.casio-intl.com/asia-mea/en/news/2012/fx-cp400/
(thanks Adriweb for the links)

The download links are http://www.ocf.berkeley.edu/~pad/files/cmonster-ti8c.zip & http://www.ticalc.org/archives/files/fileinfo/453/45345.html
The sibling topics are http://www.cemetech.net/forum/viewtopic.php?t=9152 and https://tiplanet.org/forum/viewtopic.php?t=11804 .

I've created a new Windows build tonight.

Changes between the first TILP II 1.18 Windows beta build and this one:
* bugfix: applied patch by Benjamin for fixing 84+CSE screenshots;
* bugfix: removed "UsbKernel" option from the cables list in the TILP UI, that has been outdated for many years now (but people still occasionally try to use it);
* addition: functions for sending and receiving lesser-known DBUS commands (29 / 2A, 2B / 2C, 6E, 47 / 74) for the 83+ family. Missing: 89, CA, B7.

The usual links:
* Windows installer download: http://tiplanet.org/beta/setup.exe .
* Source code: https://github.com/debrouxl/tilibs + https://github.com/debrouxl/tilp_and_gfm .
* patches not yet committed to Git: http://tiplanet.org/beta/0001-libticalcs-add-support-for-several-DBUS-commands-for.patch .
* install script for anything non-Windows which is handled by TILP: http://lpg.ticalc.org/prj_tilp/download/install_tilp.sh .

There's a somewhat newer version of TICT Handle Explorer (tthdex), which can identify more handles, in the TI-68k Developer utilities, but it's not maintained anymore, and it predates the advent of the 89T.

hoffa has been in a place without Internet connectivity for a while, and I don't remember how long it's supposed to last, so you're unlikely to get a reply from him soon...

BTW, I know of a Joey whose family name starts with M and whose interests include text adventure games... is that you ?
In which case, FWIW, porting the TI-68k/AMS "advint" to the Nspire series would require porting all platform-, OS-specific code to the Nspire's OS / nSDL / some toolkit written on top of nSDL.

Thanks for the report

Adriweb managed to get a ROM dump from his 84+CSE, so 84+CSE ROM dumping is at least not completely broken (anyhow, it worked for Benjamin before he sent me the patch). I should be able to get a 84+CSE in the next few months.

Odd. TILP being a 32-bit application, AFAICT, it's supposed to use the 32-bit GTK+ runtime.
What GTK+ runtime are you downloading (link) ?

Good, thanks

The TILP II 1.18 development cycle has officially started

Changes from TILP II 1.17 are few, but important:
* switched the development trees for libti*, gfm and tilp from SVN to Git. Two main repositories are used: libticonv + libtifiles + libticables + libticalcs on the one side ( https://github.com/debrouxl/tilibs ), gfm + tilp on the other side ( https://github.com/debrouxl/tilp_and_gfm ). The http://lpg.ticalc.org/prj_tilp/download/install_tilp.sh helper script has been updated, you need to re-download it !
* 84+CSE ROM dumping through both I/O ports, by Benjamin Moody;
* 84+CSE screenshots through both I/O ports, by Benjamin Moody (with minor torture tests and translation updates by me).

Sadly, I haven't yet been able to test the new changes on a real 84+CSE...

Mid-level functionality for Jonimus' ROM dumper shall be integrated by creating a fifth libti* library, and moving some common code from gfm, tilp, titools and probably tilem into "tiopers" (current working name for that new library). Jonimus' driver-less Windows serial port backend is planned to find its way into the libticables code base as well.

The usual links:
* Windows installer download: http://tiplanet.org/beta/setup.exe .
* Source code: https://github.com/debrouxl/tilibs + https://github.com/debrouxl/tilp_and_gfm .
* patches not yet committed to Git: none this time
* install script for anything non-Windows which is handled by TILP: http://lpg.ticalc.org/prj_tilp/download/install_tilp.sh (updated !).

It's natural that the linking software freezes, and it can occur that the calculator freezes. Try again

Yes, but TILP II freezes all the same when the calculator fails to reply, following the exploit triggering.

Some overhead for launching a native code program occurs even when the target program is unarchived (which opens the door to data losses in the event of a crash / power loss, of course). It is very likely that launching an unarchived ASM program is faster than launching an archived ASM program, due to the overhead of creating a twin, though I don't remember benchmarking that aspect.

TI tried to make it hard to launch a native code program from another native code program. The net result was the development of such radical approaches as patching the OS to completely disable the silly RAM execution protection (HW2Patch, HW3Patch and tiosmod+amspatch; modern versions of PreOS do it as well, but it's not as easy to detect as an OS patch). Being the maintainer of / a contributor to some of the program launchers led me to explicitly advocate, for at least half a decade, to just rely on OS patches for disabling the RAM execution protection.
It just makes programmers' lives easier, and has marginal impact on users: not only users have to patch the OS just once (each time they transfer a new OS version, but that's a pretty infrequent operation), but as far as 89T users are concerned, there is simply no other sane way to achieve multi-chunk programs with two-way control transfers between chunks. Everybody is happier (programs are easier to make and smaller) when the silly RAM execution protection is disabled, as shown by the http://tict.ticalc.org/downloads/launchmultiple.tar.bz2 PoC.