What about a getkey-style scanning function? It check for any open keys and returns them, possibly with multiple key detection! that would be cool.

Not quite what I was thinking, more that programs can support either without having to be reassembled. I'm thinking you'd have a few generic keys, like KEY_ENTER and KEY_UP, while if you need more controls you switch over to KEY_NSPIRE_THETA and so on. This would be the most helpful with the touchpad, since many keys are labeled the same. Using KEY_NSPIRE would require the Nspire Keypad, but it could support both the touch and the original, sans sin, cos, tan, and any other changes.

Can the touch's keypad support more than 16-directional input? I'm curious if it's really an upgrade, since the original keypad can only support that much.

I updated the Common+.h in my last post.

Interesting...the nspire has an 8-directional Dpad, so up to 16 directions. Not too shabby!

I was thinking about making a non-specific keypad library, that would detect what keypad you have (anyone know the bit that determines this? It's a hardware thing running to one of the keypads, I'll bet) and then substitute keypad commands and such, so touch, 84+ and regular nspire could all be run with the same header.

BTW, I started out just peeking at the common.h, and found something I thought was rather irritating. They only set black and white as color values beforehand, so I wrote in 16 new #define lines.

The original BLACK and WHITE commands are intact, so it should be 100% compatible with old stuff while making grayscale easier to write. I simply defined COLOR0 through COLORA for Black to White and gray in between.

Like so:
Original:
#define BLACK                   0x0
#define WHITE                   0xF
New, improved:
#define BLACK                   0x0
#define WHITE                   0xF
#define COLOR0               0x0
#define COLOR1               0x1
#define COLOR2               0x2
#define COLOR3               0x3
#define COLOR4               0x4
#define COLOR5               0x5
#define COLOR6               0x6
#define COLOR7               0x7
#define COLOR8               0x8
#define COLOR9               0x9
#define COLORA               0xA
#define COLORB               0xB
#define COLORC               0xC
#define COLORD               0xD
#define COLORE               0xE
#define COLORF               0xF

Like it?

OK, thanks! So, just to check:
If, then, function loops, while, for, that stuff is supported, but

Disp, PrintL, Print, Input-ish commands are not, as they're hardware specific.

Does that sound about right? Thanks for the help!

Does the viewscreen have a higher resolution than the regular calc? USB ones might, for 92 and 84+ cross compatibility, but I don't think the ones with the inch-long plug have a different resolution. That'd be cool, if we could have a TI-84+ with a TI-89 screen attached.

BTW for just a bigger screen stick some paper behind the viewscreen and it's nearly as bright as a regular calc screen, and much larger.

I was thinking stuff like getKey, sprite functions, maybe your raycaster eventually. Anything that People suggest would make programming easier, really. USB drivers, really long and overused blocks of code, various hardware implementations. suggest it and it would probably get thrown in there.

One thing that I would definitely want, though. It can't break compatibility with old programs every time it updates, unless it's a big fix. Like, a DispSprite command couldn't swap the X and Y. That would drive me (and many others) nuts! just think, you've been working on a program for two years, and the headers get updated. You think "ah, why not update?" Then, your program doesn't build, or is extremely buggy. For extreme variations it would probably be better to give it a new header.

that's exactly what I was talking about, DJ!

Good to know! by precomputed, do you mean they're immobile? Won't that cause problems with movements of enemies?