Yay Blackadder. I'll be humming that all day now.

The greatest feature is the lack of collision detection? Wait, what?

Looks good ;)

Lack of ending levels, lack of scoring, only 3 enemies, lack of explosion effects... Yes, there's a lot to do. [grin]

And the world will never know thy greatness :(

looks great and the music rocks ;)
one thing i would like to ask is do you care about framerate indipendent movement? or does it run stable enough at all times so you dont need this?

since i started coding games i always wanted to know hot this is managed on consoles, and now that i want to start a bit coding on the TI-92 plus it might be usefull to know that too ;)

Regarding framerate independant movement;
On the Game Gear, this is very simple. You don't. [wink]
The reason is quite simple - the VDP (Video Display Processor) on the Game Gear has some internal storage (VRAM) which holds all the 8x8 tiles that make up the sprites and background, a large table that is your "map" for the background, a table to hold all the coordinates of your sprites, a palette and so on. As it produces a video output signal by scanning down the screen it needs to access these areas of memory, and therefore changing anything or accessing any of the VRAM during this sweep will cause nasty things to happen.
How, then, does one write to the display?
There are two ways - firstly, disable the screen. This stops the VDP from outputting anything, so it doesn't need to access any VRAM so you can read/write all you like.
However, disabling/reenabling the display causes the output to flash, so it's only really any good for loading large chunks of data at the start of a level.
The other way is to wait for the vertical retrace (which can be accessed through port hardware $7E) to hit the bottom edge of the display, write to the VRAM like crazy whilst it's not currently scanning the active part of the screen (and so the VDP isn't accessing the VRAM) and hope that you don't have too many writes so that you're still writing when it reaches the top of the display again. As such, everything is tied to the vertical retrace count, (which scans at a constant rate) so you're always operating at the framerate of the display.
For something like a calculator; well, I only know this from the TI-83 Plus.
The display controller on the TI-83 Plus is very different to that of an SMS/Game Gear, because it is not designed to be constantly retracing a CRT. With that, you set (x,y) write and just output values which are sent to the LCD. In this manner, you can build up a screen in RAM taking as long as you like then send it all to the LCD in one go without any problems. However, the longer it takes to build up your image, the slower the framerate of your game - and how do you handle this? I've come up with a number of solutions;

• Ignore it. Let the framerate drop slightly when drawing lots of stuff to the screen. (Fire Track II for the TI-83 plus does this, there is some slowdown when there are lots of explosions on screen.
• Make most of your graphics routines take up a large portion of time in relation to the rest. This is why FT2's slowdown isn't too bad - I went over the top with smooth-scrolling backgrounds and a parallax scrolling background, which take up most of the time in comparison to a few extra sprites.
• Perform dummy operations when you know something is going to be slow. For example, in your inner loop, just increment a counter. When it is finished, for faster operations you'll have a low count, so do something else until that counter is the same as when processing a lot of data (so artifically slow down the faster cases).
• The TI-83 Plus Z80 can be switched into a useful IM2 mode, which calls an interrupt routine approximately 200 times a second (based on current battery level - the TI-83 Plus CPU is sloppily timed with a RC circuit, not a crystal). Use this to increment a "tick count", and use that for frame-time based movement. This is much more horrible to code for, though.

thanks for the answer :) was very intresting. so it seems like its different from system to system. gonna read the ti-92 coding manual then ;)