I think most of those are in the works. I dunno about changing the interface, but once the source is released there's nothing stopping us from doing that ourselves. Also, [Clear] worked for me. [Vars] might work, too, just because it's the same value as [Clear]. If [Vars] is stopping it, then other keys in that row ([Math], [Prgm], etc.) should stop the player, too.

Also, since the 82/83 version don't support external files, i think it'd make more sense to wait until the main engine is a little more developed/closer to its final state, that way you don't have to worry so much about keeping track 2 different engines or filling your code with conditional code à la Phoenix Anyway, i have a feeling the programs will be written for the 82 then ported to the 83/+ afterwards. But i agree, external files for songs would be nice. As it is, the songs are stored in the program itself, so if you want to share you'll just have to transfer the entire program over.

Just ask them why they bought a smartphone if all the games they play run on calculators (Doodle Jump, CubeRunner, Fruit Ninja, etc). I don't know a lot of people really using their smartphones at its real potential (like playing resource demanding 3D games such as RavenSword or something) so really, if they use it like a calc, what is the difference between the calc and the smartphone ?

Can your calc take pictures, make phone calls, send text messages, surf the internet (maybe?), have speakers for sound/music and a touch screen, etc.? Also, some smart phones might even be cheaper than an NSpire.

I agree, the design does look nice, but i don't know how i feel about the control pad.

The cool thing would be if somebody made a game where collision detection can be altered in a way so that you can walk on mountain tops, but only after climbing up stairs and you can't go straight from a mountain tile to a regular floor one.

That's not that hard to do, my ticoncours entry supports that Essentially you add an extra byte (well, nibble) of data to each tile saying which way you can enter that tile, so a tile to the left of a stair would be marked unpassable coming from the right (but you can walk into it from the top/bottom/left) and the other way around for a tile to the right of a stair. You could modify that idea a little bit to make things like bridges, too.

If you assemble for ion it's likely you can do the 83/83+ port in one go. I don't know how much saferam you need, but i'm pretty sure the 83 and 83+ have more than 82. I know for a fact that the 83+ has more. If you need any help with either, i'd be glad to help (though my testing will be limited to using TilEm2)

The 85/86 have a memory mapped LCD, you should just be able to LDIR it over. I actually looked up a lot of equates between the 82/83 not that long ago, i can't remember what i did with the information i gathered though. D_LM_STR sounds like _VPutSN. B = the number of characters to display. I also have it marked as _ClrLCDFull, but it should clear the LCD without erasing the gbuf. CR_GRBCopy is a CrASH routine? If so, then ionFastCopy is probably its equivalent. If it's an OS routine (much slower), you've got _GrBufCpy. _SaveDisp copies the LCD to a buffer starting at the address in HL, i'm not sure if that's what you want or not. If you just want to copy the gbuf to another area in memory, you can just ldir it. Altogether it's like 10 or 11 bytes.

The 83+ is 6MHz, as are the 83+SE/84+/SE. The 83+SE/84+/SE calcs also have a 15MHz mode, but you'll have to specifically declare it, by default they run at 6MHz.

The 82 Stats.fr is essentially an 83. I'm not exactly sure what the 76.fr is, but i believe it can also run 83 assembly programs without any issue.

EDIT: And i would release the source anyway, even if it's messy and unoptimized. Messy and unoptimized source is much better and more useful than no source at all I'd love to help with an 83+ port, but i have no way of testing if it actually works or not. I don't have any fancy earphones or even a radio to test with

@chickendude yeah it's super hard, but it's still doable, and that's the point of danmaku-s also, moving fast isn't a good thing, since in hardest levels you'll have to be very accurate to dodge all of the bullets. Maybe I just can make the player accelerate wheh alpha is pressed, so you can measure precisely your moves. And thanks for the feedback

I was more talking about after you hold a key down for maybe a second it would start to move more quickly/accelerate, but it's not that important.

How is the screen handled? If it's not what you're doing already, you could just use the fastcopy routine to erase the gbuf as it copies so you don't have to xor the sprites twice to erase them. That way, when you get hit, you can just skip drawing the player's ship sprite every other frame (or only draw it every 4th frame), something like:
ld a,(invisible_frames)
and $1
 ret z

or:
and $3
 ret nz

I think the flashing animation would look nicer than the rectangle. I know you said it's not definite yet, but 64 frames feels like a long time, i'd cut it in half. (or less).

Also, a 2nd level?! I can't get past the first

Dapianokid, people have been using that method to open gameboy cartridges (and probably many other things) for well over a decade now Still, it works pretty well to open those weirdly shaped screws.