There is only one SNES emulator that works both fast enough and supports most games: Snes9x.
ZSNES is x86 only, so it won't work on Nspires. I tried a quick port of Snes9x, but didn't succeed, all I got out of it was a frozen black screen.

Quote from: Vogtinator on April 21, 2015, 05:25:27 pm

Quote from: Sorunome on April 21, 2015, 09:23:43 am

Thanks, I found another ground loop - either my laptop or my desktop sound card is designed badly: you can create a static noise on line out if they have a common mic on line in.

So you have essentially a T-connector for your microphone? That's not really a good idea, noise won't be the only issue here. You can try capacitive coupling, around 330n should be enough.

That only reduces any DC offset and other low frequency interference. The signal grounds should be isolated from the power supply's ground and most importantly from eachother.

Here is some more reading material:
http://books.google.nl/books?id=PvKPEFu2PVkC&pg=PA344&redir_esc=y#v=onepage&q&f=false

This differential input also rejects any common mode noise: Static noise introduced in the cable. Because the difference between the two signal wires is amplified any noise common to the wires is not amplified.

If you design it correctly, you won't need a differential signal for audio. Just make sure that not more than one device is earthed.
You definitely need to connet all signal grounds together, otherwise the shielding becomes useless and will in fact introduce even more noise.
The decoupling is needed to make sure that both input devices don't interfere with each other, to get the best signal out of it you'd even have to calculate some resistors in series with the caps for impedance matching (audio is normally about 200 or 400 Ohms).

Thanks, I found another ground loop - either my laptop or my desktop sound card is designed badly: you can create a static noise on line out if they have a common mic on line in.

So you have essentially a T-connector for your microphone? That's not really a good idea, noise won't be the only issue here. You can try capacitive coupling, around 330n should be enough.

I actually thought about writing an interface to use nGL from within Micropython, but in the end it'll be too slow.
I would have to implement a new data type (GLFix, fixed point) that is not supported by python directly, using floats wouldn't be fast enough.
It would definitely work, but it won't be fun.

Anyway, I designed nGL in a way that makes it fairly easy to use, without any complex language constructs.
Knowledge of C should be enough (although the files have to be C++) to get a decent nGL app running.
Also, to just do some basic 2D graphics I'd recommend looking at other libs which aren't optimized for "heavy" 3D graphics like SDL or n2Dlib.

Uname says 4.0.0-rc7-next-20150410, but my usb thumbkeys won't work for some reason. lsusb ends without any output, no reaction on dmesg and no new device in /dev either.. (doesn't matter whether I connect otg before or after linux  boot)

I started a new kernel build with some more options activated, but there was no obvious USB-related option missing.
Are you using a CX or classic?

Edit: http://tiplanet.org/nspire-linux-builds/devicetree/zImage_expanded_20150418_1650.tns

I can't guarantee that my otg adapter works (a little wonky construction), but it did with the old kernel and when pluggin it in while in Nspire OS it complains properly about a device connected it can't handle

That's a good sign that it's at least enumerating properly, so it should leave a linux syslog message.

lsmod end with "/proc/modules: No such file or directory"

Modules aren't enabled.

http://tiplanet.org/nspire-linux-builds is running again, with linux-next builds and up-to-date buildroot images.

You have to build the "new" SDK from source: http://github.com/ndless-nspire/Ndless
On Windows, use Cygwin, on linux it should work directly. fstream is fully supported, as is everything except threads.
See also http://hackspire.unsads.com/wiki/index.php/C_and_assembly_development_introduction_on_Linux

For a calculator, you shouldn't have to do perspective corrected texture mapping. You get almost as good results from affine texture mapping if the textures aren't stretched too much.

That's correct, nGL doesn't use the Z coordinate for texture interpolation. It simply maps the triangle edges to screen edges and interpolates linearly.
That's still two divisions per scanline, but the memory speed is the limitation here. The CPU on the nspire is fast enough to do calculations, but the RAM is really slow.

Suppose that I wanted to draw "Hello" on a wall. Instead of drawing the pixels that make up the 'H', I could instead store the 3D lines that make it.

How well does that scale? I assume you're not using a z-buffer, but sort the faces before drawing. (Surprisingly, a z-buffer is faster than sorting faces on the nspire, even for moderately low-poly scenes)