From a technical point of view, "SendMessage timeout" means nspire_emu has entered the debugger because of the bad word read, and cannot process the action you are requesting from the GUI menu.

Anyway this doesn't explain this bad word read.

apcalc, I'm thinking of using Block Dude as a screenshot or video tutorial for the upcoming GDB support of of Ncubate. Wouldn't you mind?

I am also thinking of adding RLE compression to the saved state files. I don't know how it runs on your side, but my laptop is quite old and restoring a 32MB file to memory is painful for its slow hard drive.

What about a C/ARM xLIB/Flib for TI-Nspire?

I got several problem reports with Nldess v1.1 and Computer Link Software v1.4 in the past few month, unfortunately none of which I can reproduce with my own configuration (32-bit Windows XP, Windows Vista and Windows 7 on two different computers).

Many bug reports are specific to the users's configuration and seem not to depend on Ndless itself (see qazz42 reinstallation of Computer Link above, that changes the error). The only issue reported by several users is the following error during the installation:

- Transferring loader
ERROR: The transfer cannot be completed because the computer file or folder could not be accessed.

Ndless v1.7 is at the moment not ready for a release, so I would like to make the v1.1 branch fully stable.

Ndless v1.1.1 is available: it is a maintenance release trying to fix the issue above (altough I can't test it). It also includes a diagnostic mode. Anyone who had issues with Ndless v1.1 can please try this version and send me the diagnostic file as described in the ReadMe if there are still any troubles.

* v1.1.1 - <2010/10/16>
 Installer:
  - NEW: Diagnostic mode for problem reports (see "Troubleshooting" above)
  - CHG: Change file transfer path handling, which may fix some transfer errors
 Include files:
  - FIX: isKeyPressed made sometimes the program hang

Yes it seems, see the link in my reply above.

DJ Omnimaga: optimization is most of the time required only on a subset of the code. C has the advantage to make coding faster, and add a level of abstraction to the code (named variables, structures, stack management, ...). And it's true that a good assembly programmer will make a better job than a C compiler.
To my mind mixing C and assembly is the best option to get both performance and better maintenance.

cal84maniac: maybe you have good reasons for not telling us what you are planning with the emulator, but I'm also quite curious about it. I suppose the options are either 1) not to release it at all  2) release it as-is   3) Wait for time/motivation to reverse-engineer it or rewrite it and make it releasable.

@Lionel Debroux: Well, I must be really behind!
I still think it's BSD, or at least has some BSD parts in it. Lookie here:
http://www.google.com/#hl=en&q=usbd_start_next%3A+error%3D%25d&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=76ee7718c2ec583d

The interesting text is "usbd_start_next: error=%d". The google search above yields plenty of BSD source links. How isn't it BSD?
This was found in the latest stock OS, 2.1. Line 8752 to be exact (after extracting phoenix.raw, and "strings"ing it).

You're right. Looking closer:

"*BSD"'s usbdi (and ehci) interface was introduced in OS 2.0 (apcalc points out that this could be required to support the docking station).
Some parts seem to be deeply adapted though.

This means that:
- TI would be in violation of the BSD license. The license requires that any distribution in binary form reproduce the copyright notice, conditions of distribution and disclaimer. I can't find these requirements.
- Understanding/hooking the USB stack and documenting the USB I/O ports may be easier thanks to this open interface