Hello,Sorry for the long delay. I have included in this entry my thoughts on simulating the position, velocity and acceleration of the lander in the game. Comments, thoughts, corrections are always welcome.

; Ship position, velocity and acceleration implementation.; =========================================================;; The ship position shall be stored internally in 4 bytes per axis.  Below is; a diagram of the 4 byte value and below that is a description of each section.; ; %NNNNNNNN ssssssss dddddddd dddddddd; ; The first byte declares the screen the player is on.  The game play area; is a grid of linked screens.  The first byte of X and Y pos sets place the ; ship within the grid of screens.;; The second byte is the integral scanline/pixel position of the ship within; the current active screen.  ;; The 3rd and 4th bytes are the decimal portion of the ship's position on that; axis.;; The X&Y position is interpreted in software as follows:;	- Given:;  ShipY = char[4];  ShipY = char[4];  Maginification = enum { 1x, 2x } = 1x;  ShipDisplayY = char;  ShipDisplayX = char;  ActiveScreen = struct { baseX, baseY, Scale(1x/2x), Landing Zones };	- The code will look at the 1st bytes to determine the active game screen;	- The code will search a list of zoomed areas within the active screen.;   The second bytes of X and Y are compared to the zoom boxes.  If one;   matches, then the active screen is set to the zoomed screen, and the;   magnification setting is changed from 1x to 2x.;;	// NOTE: Each active screen is 128 scanlines tall and 128 pixels wide.;	// The actual displayed screen is larger than 128 x 128, but when the;  // ship leaves a 128x128 area it has entered a different active screen.;	// At that point the ship position wraps to the other side of the active;	// screen and the landscape rendered on the screen is updated.;  // So based on the dimesions 128x128 we say that the upper 7 bits;  // of the second position of each axis shall form the on screen;  // position of the ship within the active screen area.;;	// Within each active screen there are 0 or more zoomed areas where all;	// dimensions are magnified 2x normal.  For that case, we use the full;	// second position byte offset to the origin of the zoomed area to find;	// the X and Y Display values.  Including the least significant byte will;	// effectively mulitply the ship position resolution by 2x.;	- IF Magnification = 1x THEN;  - ShipYDisplay = ShipY[1] / 2 + ConstantYOffset <=(8 diagram see below);  - ShipXDisplay = ShipX[1] / 2 + ConstantXOffset;   ELSE // Magnification is 2x;    - ShipYDisplay = ShipY[1] - ActiveScreen.baseY	+ ConstantYOffset;  - ShipXDisplay = ShipY[1] - ActiveScreen.baseX	+ ConstantXOffset;   ENDIF;  ;	Here is a simple diagram that will hopefully clarify the above thoughts:;;             Pixels;           |<------- 144 ------------->|;           |   |<------ 128 ------>|   |;           | 8 |                   | 8 |    	;           V   V                   V   V;   =======>+---------------------------+;     |  8  | Rendered Screen           |  ;  S  | ===>|   +-------------------+   |;  C  |  |	|   | Active Screen     |   |;  A 144 |	|   |                   |   |;  N  |  |	|   |                   |   |;  L  | 128	|   |                   |   |;  I  |  |	|   |                   |   |;  N  |  |	|   |                   |   |;  E  |  |	|   |PF1 |PF2 |PF2 |PF1 |   |;  S  | ===>|   +-------------------+	|;     |  8  |                           |;   =======>+---------------------------+;        |  | Control panels            |;       48  |                           |;        |  |                           |;     =====>+---------------------------+;;	Velocity:;	---------;	The velocity in each axis shall be represented by a signed 32-bit value.;   Each frame we will add the velocity for each axis to the 32-bit position;	value.   This is an overkill approach since by my calculations a 18-bit;   value would cover all the possible velocities for a lander game, but I ;   don't have a shortage of RAM, so I will go ahead and waste 3+ bytes. :P;;	Accelleration:;	--------------;	Every frame the lander is accelerated by gravity, and by one or more ;	lander thrusters.   Gravity is simply a constant applied to the vertical;	velocity accelerating the ship downward.  The thrusters will we implemented;	as a table of constants indexed by the rotational position of the ship, and;	added to the X and Y velocities.  We will apply all acellerations for a ;	frame before applying the velocities.  ;;	I am also thinking that the main thruster should take 3 or 4 frames to ;	increase to full thrust.  The easiest way to do this is to have the thrust;	values in the table be the minimal values that we multiply by a factor ;	reflecting the time the thruster has been active.   The resulting game play ;	will be that a single burn of N frames will produce more thrust than;	multiple burns spaced over N frames.  I plan that fuel consumption per frame;   of active thrust will be constant, since that will reward the player who;	lands with the fewest firings of the main thruster.;;  The actual constant value to use for gravity is going to be a challenge to ;	get right for comfortable play.  Acceleration on the moon is 1.62 m/s2.  It;   is simple enough to simulate that in the game; we just need to decide how;   tall (in meters) a scanline is for our simulation and then calulate our ;	constants from there.  The trick is picking a scale for the game/ship that;	produces a comfortable and enjoyable feeling for the player.   The main;	thrust must be strong enough to feel responsive, but not easily overpowering;	making it too hard for the player to set the ship down.  I suspect the;	correect values will become evident with actual game play.   I believe the;   actual value for lunar gravity will be usable, but I am willing to reduce;   its value for the simulation if it makes the game more fun to play.;

The code option on the forums butchers my formatting, so I will attach an image of the diagram from above. Cheers!