The pod's maximum speed is 4.0 pixels per frame. This can only be done by tethering an object and having it pull you along. If your thrusters or the gravity attempt to accelerate the pod in the same axis, it will instantly reduce the speed to a maximum of 3.0 if the pod is traveling faster.

Thrusting enforces a maximum speed of 3.0 pixels/frame.

The default thrusters accelerate an unburdened pod at 16, when facing straight into some direction. Carrying an object will cut this acceleration by varying amounts depending on object mass.

Thrusting straight right (direction 8) or straight left (direction 24) will count some thrusting force upward, and will prevent reaching

Basic thrusting with default thrust or Double Strength Thrusters take 2 fuel per frame, or 16 fuel when using boosters. Efficient Engines reduce the costs to 1 or 8 fuel per frame, respectively.

Gravity enforces a maximum downward (or upward, if reverse) speed of 3.0 pixels/frame. Even zero gravity is counted as downward with zero acceleration, and will enforce the downward maximum.

Gravity usually pulls the pod down at a constant rate, depending on the planet. There may be areas on a planet submerged under a fluid of sorts. The only affect of entering one such fluid is a change in the acceleration of gravity. There's still no friction.

Anti-Gravity completely shuts off gravity when active. Downward acceleration, speed maximum, and tethered object will not be affected by gravity with this item in use.

The pod can face 32 different directions.

Straight left (24) or straight right (8) is still counted as a thrust upwards of usually zero acceleration. If you desire to travel faster than 3.0 pixels/frame going up, avoid thrusting in these directions.

Straight down (16) or straight up (0) is not counted as thrusting either left or right. There will be no interference for horizontal momentum that exceeds 3.0 pixels/frame.

Tethered objects are impacted by gravity in an intuitive way. By accelerating in the opposite direction of the motion of a tethered object, player actions can also help increase the tethering speed. The faster the tethering speed and the heavier the object, the more it influences/accelerates the player's speed. Generally speaking, this is again done in an intuitive way. But please note that there are oddities in how the game calculates the resulting pod speed. For example, continuously thrusting in the opposite direction of the movement of the tethered object will not necessarily result in generating the most speed. Some thrusts have more impact for the speed than others. And some thrusts even have a negative impact on the speed, even though they intuitively should instead be contributing. The underlying mechanics have not been investigated in further details, but are important to take into account when TASing, even if it's only in the form of playing around with inputs by "trial-and-error".

So for example, when travelling to the right, a tethered object will accelerate the player when moving in front of the pod (doesn't matter if the object is moving clockwise or anti-clockwise around the pod), up to a speed of 4p/f. Once the tethered object crosses the vertical line of the pod to the left side, it will start to decelerate the player. If the object comes to rest, it will no longer impact the pod's speed, even if it's off-center with respect to the pod. This speed-up mechanic is significantly more efficient when traveling to the left than when traveling to the right. The reason for this has not been investigated.

Vertical motion is impacted by tethered objects in a similar way as horizontal motion. The main difference being that the gravity fields of the planets prevent the pod from speeding up above 3p/f (not applicable to large wormholes!). This limitation can be bypassed by activating the "anti-gravity" upgrade. To speed up for example downward movement, place the tethered object above the horizontal centerline (or below in an inverted gravity field), the higher the better, and let it freely fall down. When it's about to pass the centerline, ensure the pod's y-speed is already 3p/f and activate anti-gravity. While the object swings below the pod, it will accelerate the pod up to a vertical speed of 4p/f.

The value at address 005A is affected by the following:

The thing that matters is the fact 005A is affected by direct controller input. This includes Player 2, which has no effect anywhere else in the game. By using Player 2, it is possible to gain very strong control over how the RNG works.

The values at address 005B and 005C are left-shifted every frame. The bit shifted into 005C is an XOR of bits 0x40 and 0x08 from 005A, although it has been observed to, on rare occasion, shift in an opposite of this bit. The bit shifted out of 005C is shifted into 005B, and the bit shifted out of 005B is thrown away.

Since 005B and 005C are affected by what happens with 005A, and 005A is affected by controller input, this means you should have complete control over the RNG.

During game play, you have control every other frame, but the RNG runs every frame. As the RNG "ticks" twice for every frame you have control, this makes it somewhat difficult to set the RNG perfectly.

All three RNG addresses are used for various random events.

The top eye can be despawned during the auto-scroller, well before the actual boss fight begins. This can be seen by monitoring the eye state address $0461. At the time of writing, the best description for what happens is found here: Forum/Posts/367718 . There have been no reports of additional eyes being despawned (or other eyes than the one at the top). The bot 'Jaffar', created by TASer 'eien86', was able to quickly find solutions that despawned the top eye, but did not find any other variants.

When the window gets "close enough" to the boss, the eye timers get initialized one-by-one to 0 and will then start ticking up every 8 frames. This appears to be programmed in a set pattern, meaning the start order of the eye openings is always the same. Note that small variations have been observed, so there appears to be a little room for manipulation in the timing of the first eye openings, but this has not been investigated in detail.

When an eye timer reaches 0x20, the game will branch at instruction $C08C to the piece of code for the eye opening sequence. The sequence is split in 8 segments, each consisting of 8 frames. The first and last consist of the eye being half-open (and not vulnerable). When the eye opening sequence begins, the game will also re-initialize the timer for the next phase. This is done by comparing one of the RNG-addresses and 0x1F. The result is written to the timer and becomes its new start value. The eyes with index 0, 2 and 4 use $5B for this and the eyes with index 1 and 3 use $5A. Since the RNG-addresses can be manipulated (see section above), the player has control over all eye openings at any time, except for the first cycle as explained above.