If you had a Prizm, you'd be better off writing it in C; for an Nspire, you'd want to use Lua. Of course, the Nspire Lua library doesn't have an I/O library (as far as I know?) so a shell might be less than useful.

Heh - yeah. I would imagine rewriting it in C wouldn't be terribly difficult (or at least not as difficult as rewriting it in ASM, which is incredibly hard and I applaud you for doing that)

That's even worse than the time cutoff I suggested earlier, because a particular BASIC program can only do a fraction of the calculations that the same program can in ASM. Something that I did state is that the time cutoff would only apply if all the entrants in that particular round were the same category (e.g. all TI-BASIC or all ASM), because that's the only time when a speed limit would be fair. And, as an extension to that, whatever library we use to allow TI-BASIC to communicate with CALCnet has to force the BASIC program to run at 6MHz.

Do you think GlassOS/C applications would be acceptable for this contest if it HAS to be on a proper calculator? From the looks of it, AHelper has made a nice API that will be able to produce lean binaries, free from most of the bloat that the TI-OS targets of the C compilers make from dumping in library functions.

That was the purpose of GlassOS.

What about pathfinding? Given a map with obsticles, find out which program gets to a destination the fastest with the least amount of time calculating.

*AHelper should give suggestions that he would be interested in doing :-\

Oh, I like that one a lot too! We have a lot of good ideas in this topic; the trouble is going to be narrowing them down into something everyone can agree on.

Yes Kerm I do and I mean like adding other features like extra guns to ti doom and extra blocks to TI-Craft

Eh... no that wouldn't be very useful. What would be useful would be a computer program that you run after plugging a Nspire in, that then weirds out the Nspire all over the place and makes it have a wonderful Doors-like shell (a hack)

Compynerd:

You wouldn't put BASIC programs and ASM programs in the same category if you were to do that...

How about a DCS7 apps, utilities and extensions. They could be written in both ASM and BASIC, although, this would restrict the contest to users of the TI-83+/TI-84+ lineage of calcs.

I'm still very much in favor of that. I'd say that our frontrunners are currently:

1) Doors CS-based apps, utilities, games, and extensions, that must be written in BASIC, ASM, or Axe, and use some of the features and libraries of Doors CS. A simple DCS header would not be enough.

2) A hack-n-mod contest, where you must take some existing program or game and (with the original author's permission) mod and hack it to be extra-awesome. Points would be given for optimization of the original, new features, creativity, and use of libraries.

3) A CALCnet/distributed/AI contest, where entrants are given a skeleton framework that connects to CALCnet and sends and receives data. Participants must use it to solve some random permutation of a problem in as little time as possible. Options include game AIs and path-finding.

Didn't we already have a Doors CS themed contest? Also, when does the contest officially start?

Yes, we did indeed have a Doors CS-themed contest. Not to say that we couldn't have another one. I'm thinking of starting it November 1st.

You should enter the contest by porting DoorsCS (the gcn protocol) to GlassOS. That would be in second if the nikky simulator is also entered.

<edit>

Well, your criteria above would rule any GlassOS stuff out

AHelper: maybe you should write a calcnet implementation for GlassOS!

Do you mean the BASIC, Axe, or ASM rule? Because that appears to only apply to Option 1, which is the DCS-based programs. Option 2 has no limits, right?

Not that a contest should be an excuse to port gCn to GlassOS anyways. And since Kerm has published the exact whitepaper for CALCnet2.2, it should be quite possible to write the protocol in C.

CALCnet != gCn. The calc doesn't support the IO port. I am talking about gCn connectivity for glassLink to be called from GlassOS.

Wait, why doesn't your system support the IO port? Did you just not write it in, or is there something else going on with GlassOS?

But yes, writing the USB equivalent of the protocol will work nicely.

What about a broad contest for anything related to Cn? The goal could be "best use of the CALCnet framework."

I'm just thinking that a Cn contest would be a great idea, but what you're suggesting sounds like something that only a handful of people would join (since there are so many game designers in this community).

I want to include BASIC programmers, too, so I wish there was a way to interface CALCnet with BASIC in a sane manner. If anyone has any suggestions, even for something small and kludgy that could get BASIC programs sending data back and forth over CALCnet, I'd love to hear it. The problem as I know it is that the BASIC interpreter plays games with interrupts.