the touch pad and click pad versions of the nspire are identical I have both keyboards and bought my nspire before the touch pad existed. the only reason you get an error is that the old OS's don't have drivers for the touch pad so they fail. moving to an OS pre 1.7 with the touchpad on the calculator gets an error. doing it with the clickwheel doesn't.

It sounds like they did a bios update when moving to 2.1
I actually had an interesting thought on the subject of hacking the nspire:
Nucleus is lynx based and therefor much like andriod we should be able to root it. What is preventing us from doing that? once we root an nspire you have god rights to the machine and can get at everything.

android build in browser, dolphin browser and dolphin hd browsers all run irc ok. but there is a small problem with the fact that irc refresh causes what I think is a complete reflow of the page which causes the page to flicker and browser loading bar to come up.
It would be helpful for phones to be able to do any or all of the following:
-disable Irc temporally
-pause refresh of irc (some kind of manual refresh would be useful with this)
-slow down refresh rate of irc.
It's not really a problem so don't spend much time on it. I'm just getting it out there.
tech specs:
phone name: htc droid incredible
processor: 1GHZ snapdragon (core is an arm9)
ram: 512mb
OS: android 2.1 update 1 (uses lynx kernel)
browser: dolphin 3.0.1, dolphin hd 2.1, and packaged browser (version 7) (webkit based i think)
I'm trying new skyfire 2.1 browser later

It may still be worth looking into wether the N-spire has and of these coprocessors because it seems to me the 2d via 3d stuff in the graphics coprocessor may have been applied to speed up the graphing capabilities and may also be included for doing 3d graphing like the 89 (although I don't think the n-spire line currently does this it maybe in the works so that the N-spire CAS can eventually completely replace the 89.  And if the CAS has the hardware to do something so does the N-spire.  For all I know this entire thing could turn up nothing and we'd be left where we started but if the search does turn up something imagine the gains. but that's just me being an optimist.

additionally:
there is mention of the graphics coprocessor being good for text acceleration some where in some of the random documentation I read.

this is the pdf i found

I wrote a response 2 days ago and apparently it didn't take so now I'm here typing it again. sigh. at least I have a real keyboard this time (typed last one on touch screen keyboard phone)  I agree if it were to use real 3d and textures and poly counts were carefully managed a full 3d fps should be "easy". I put easy in quotes because writing a 3d game engine is a rather large under taking.  portal would have to be a slightly longer range goal for the engine. one would build an fps first then modify the physics and rendering engines to manage portals.  portals represent a difficult rendering challenge valves portal as I understand source may have to render the world up to 5 times (default render depth of 2) in various resolutions to get an image so if possible a better way should be found (the engine has a hell of a time trying to render multiple sets of portals that are in the same room. there is a reason only one set of portals is allowed at a time. again that's if i understand correctly.)

Though the engine would have the advantage of only having to render in 4-bit grey-scale on a 32 bit processor and there for with some careful register games work addition on 5 pixels at a time and multiplication of 3 in single ops. (rough guess haven't worked it out yet I need to do some looking up on the architecture.) rendering still will represent likely over 60% of the CPU time and will have to be hand optimized in many places (because you can't always trust compilers to tile the best way possible.  Memory is also a little bit of a problem because modern day engines tend to get their speed by having half of the stuff pre-rendered by the developer and pre-rendering can make things gigantic fast. listening to developer commentaries valve seem like their jumping through rings of fire bare-foot backwards on a unicycle while playing a piano and a harmonica to so that they don't blow their memory space. I exaggerate only slightly. (they really wear shoes. those petals are ruff on the feet.)

I would like to note that this is not an undertaking I think anyone should try to solo this should be worked on by a team of the best coders on this site and a good high level design before they start. I know I'm not willing to take this on alone

As a final note: I only used portal as an example because i thought it would get the best community response. I just really what to see a 3d game engine once that code base is in place it can be easily built off of to make many games.

you are totally wrong about the way the DS it does ALL of its 3d rendering on an ARM9 clocked at 67 MHZ the N-spire is running an ARM9 clocked at 90 MHZ
from Wikipedia:

CPUs: Two ARM processors, an ARM946E-S main CPU and ARM7TDMI coprocessor at clock speeds of 67 MHz and 33 MHz respectively. The ARM946E-S CPU processes game play mechanisms and video rendering while the ARM7TDMI processes sound output, Wi-Fi support and additionally, when in Game Boy Advance mode, processes what the other processor used to do.

The DS has no vector coprocessor to speak of sorry to disappoint its just got an efficient engine.

the DS and n-spire use 2 different breeds of the ARM9 the N-spire using the highest end that has special instructions for JAVA optimization and the DS uses the second to highest end that may have more cache.  I'm almost positive this can be done.

as a note:I mentioned the ray caster because it showed that such things could be done.  To do portal one would of course need to optimize the hell out of the current ray caster or write a rasterization rendering engine