Storyline, graphics, background areas will all be big areas. Don't worry.

You could also help manage the project if you'd like. I don't want to do everything

Posting a new poll on the storyline's setting. This will affect how the gameplay works, so I figured it should come first.

That's a good point. How about having a topic specifically dedicated to RAM usage in specific areas, along with the same info on github?

Oh, and when using github, make sure to branch. It makes things a lot easier to work with. For example, you can modify ALL the codebase without actually modifying the master code branch. Also, use changelogs. Detailed changelogs.

Well, if it's in axe it should still have separate source files (not hard, thanks to the prgm token) so that we can manage the project in a more group-like context. We would also need to share it as source, rather than compiled programs. I hope no one has an issue with that.

Does Axe support compiling programs whose source is larger than RAM fits, via archive?

Ah, yes, that's a good point. Axe would be perfect for writing small routines like menus, archiving tools, etc.

We could also have multiple builds if that's the case: AsmStub and Fusion

SH processors do come in much faster than what the nspire has (the dreamcast had an sh-4 that ran at 200 mhz stock), so we don't really know. However, judging by the RAM available it's probably pretty close to the prizm, which is weaker than the cx by a fair amount.

However, it would be a small enough difference that OS design would be a big enough factor to change the speed comparison. The nspire's OS is ridiculously slow at even the most basic math routines. It gets beaten by its predecessor, the 84+ (Ridiculously lower specs) on several examples. If the classpad is written more efficiently, code-wise, it could easily outperform the nspire series.

Also, if it's anything at all like the prizm, no jailbreak will be necessary. You should be able to simply compile and send add-ins to the calc.

Well, of course i2c isn't still running in the background OS: You completely replaced it. Nothing is running in the background except what Linux knows to do. Is there a driver for the i2c protocol implemented yet? AFAIK direct GPIO works great for an i2c connection. According to wikipedia, standard protocol uses two drivers: One for the i2c itself (assuming there is a dedicated i2c chip) and one for the device connected to it. (Here, the touchpad). I think it would be a good idea to stick to that, so that if anyone ever tries to use the i2c for something else, like in a h/w project, they already have the i2c bus to work with. Plus, that should give access to any i2c device drivers that are available.

I found this wiki that may help development

Maybe we'll get lucky and find out the touchpad itself is already supported, and just the adapter needed a driver.

I don't think you understand the compilation issues that occur when transferring across architectures. There are quite a few examples of these, like different variable sizes, the fact that ARM processors default to unsigned variables, the different sizes of all the variable types, the differences in how long types work, all of these must be addressed when porting code across platforms.

The unsigned variables are particularly important. On x86, I can safely assume that when I say int a = -5, I won't end up with a huge, positive number. Not so on ARM.

That actually sounds like a good idea.

Can you see unlisted videos (as in, not in the search, but can be accessed via URL) in someone's profile?