Recently I got on the idea that the Lua print command in Nspire Lua might print to the serial console. To test this, I built a max232 TTL converter and hooked my nspire to my laptop. And yes, it printed to the serial console!
Then I ordered an Arduino Uno, with the idea to hook it up to my nspire and control stuff.

A few days ago I received it and I started working. I had some problems until today because the the voltage on serial port of the arduino was to high for my nspire, and caused a reset everytime I connected it. Today I discovered (with the help of Kerm and benryves) that its only does that when its getting its power through usb, and not the power connector. So I switched to another power supply and all was fine

The print command in Nspire has some limitations though, you can only send bytes with data 1 to 127, and its also not the only data that gets send to the serial port. To overcome these problems, I made a little simple protocol to talk with my arduino. A sample data packet (in ascii) looks like this:
nomOKOCEHONOKOFOOOO@BDFON\r\n"nom" defines the start of a data packets, and "\r\n" the end (it gets automatic added with print). 2 chars represent one byte that has been split in two (to be able to send 0-255).

My first real world example is controlling a little led display through my nspire. The arduino here just acts as a "proxy" to send the data to the display.






Sadly though I can send data (yet) from the arduino to my nspire, but if I do some work on reverse engineering the other dock connector pins, I think I'll be able to find a solution.

Edit:

This is real nice, good job Chockosta!

Currently sound isn't the most easy thing to do. It is possible, but requires lots of programming work and possibly some hardware work (like adding a resistor after the output).

That partially because he moves in big chunks. In my game, the player moves very smooth, which makes that I need many redraws.

Hm, thanks for saying this. Looks like a troll was busy ...

Well, the thing is that I don't have to draw more images if I use this. Redrawing the screen alone might be faster, but for many games that need images, the combination will be faster. drawImage really can be a bottleneck in programs, and that is why I try to limit using it with redrawing only parts.

I haven't posted many routines here, but its ok for me

Well, I'm developing a game (not saying the name :p) and the extra parameters are really important for me. Now I don't need to redraw all the images on the screen using gc:drawImage (which is slow), and I notice a big speedup. The game will be unplayable without it.