Introduction
Hello! I am ChucJo, a very new member of the Solar Jetman community and the TASing community. I came onto the scene in February of 2026 soon after my brother, Bean_of_Truth, started speedrunning the game. Although my background is in software engineering, I have never done anything like this before. I have no previous experience with ASM, reverse engineering, or TASing, but I was very motivated and found myself with some free time. I very quickly stumbled upon some revolutionary discoveries that have changed the Solar Jetman speedrunning scene, and warranted a new TAS. This game holds a very special place in heart, so this run can be considered as a "thank you" to the community for keeping this game alive.
New Discoveries
CPU Overloading
CPU overloading is a new strategy that I devised that players can implement to cause unintended behavior by the game code. The CPU on an NTCS NES has a maximum of 29780.67 cycles per frame, with each code instruction consuming a handful of these cycles. Solar Jetman is a very CPU intensive game at times, and this limit gets maxed out quite easily. When that happens, a CPU interrupt occurs that immediately stops what the code is doing and gets ready to start the next frame from the top. This allows the player to stop the code at a crucial time to intentionally cause a glitch to occur due to RAM not being in an intended state after the interrupt. While this actually has practical applications for RTA runners, this can be abused heavily in a TAS. The number of active entities is the key tool that players can leverage to control CPU usage, such as bullets and enemies.
Planet 12 Warp
On planet 1, there is a warp that is intended to take the player to planet 7. This is triggered by killing a special enemy within a specific time frame which spawns the warp. It has been known that there is a glitch that can cause this warp to be duplicated, but until recently this glitch was very mysterious and unpredictable. After an investigation by me, it was revealed that CPU overloading was the root cause of this glitch.
When a bullet makes contact with the warp enemy, a code branch executes to handle the collision. Instruction $89E6 is responsible for initializing the warp in the persistent entity array in RAM. Instruction $897B is responsible for clearing the warp enemy from the active entity array. If an interrupt is triggered between these two instructions then the warp will have spawned in and the enemy will continue to be spawned in, thus allowing the enemy to interact with the bullet a second time so that the warp is duplicated.
The planet that the glitched warp transports the player to is determined by its index in the persistent entity array. Planet 1 starts with 6 persistent entities, the intended warp is 7, meaning the glitched warp will transport the player to planet 8. If this glitch is repeated enough times in a row, then a warp directly to planet 12 will be created.
Notes:
- This array has a maximum size of 26. Glitched warps after index 13 will start to transport the player to the warpship part rooms, with the last slot being the warpship part room for planet 13. While this seems extremely useful, most of these warps will spawn the player directly on top of the warp back to the corresponding planet as this type of warp does not grant the player a warp cooldown like the intended warp to the warpship part rooms does.
- If a glitched warp is created when the array is already maxed out, this does actually overflow and start writing data to unintended locations. This does not actually create warps that can be interacted with, however. This does warrant a future investigation to see if any other glitches can be created due to this overflow.
- The game can only have 4 warps active at once (this space is also reserved for fuel cells and other similar entities, which can cause the fuel cell to be despawned temporarily). These types of entities have a peculiar behavior when there are too many close together in that they attempt to move back to their "home". You may have seen this before if you have moved many carryable entities into one area, and one of them will start to move back. This explains why the glitched warp will be moving. The warp that moves first is inconsistent, and not fully understood at this time.
Wall Clipping
Wall clipping was first seen in a Twitch stream by MickeyDadRad, where he managed to get pushed out of bounds through a wall by a sphere enemy. This occurred by complete accident and an insane amount of luck. If this footage had never been captured, this glitch may never have been demystified. After an investigation by me, this was also revealed to be due to CPU overloading.
The sphere enemies are unique in that they can push the player around without bouncing away like other enemies. If a player is near a wall when this happens, then the sphere enemy can push the player several frames in a row. Normally this causes the enemy to die very quickly, since it takes damage every time it comes into contact with the player. However, abusing CPU overloading allows us to get around this. Instruction $8902 is responsible for updating the sphere enemy's health when hit by a bullet. Instruction $8936 is responsible for clearing the sphere enemy from the active entity array if it's health is zero. By performing an interrupt when its health reaches zero, the enemy's health underflows to 255. This allows the sphere enemy to survive long enough to push the player all the way through a wall.
The player can freely move once out of bounds and can go back in bounds easily because wall collision is only one-way, although this usually cause the player to bump into the wall which deals some damage.
Notes
- The shield is required for this glitch, otherwise the player would die before being pushed through the wall.
- This glitch works better with a wide angled corner compared to a shallow angle corner.
- The sphere enemy must be moving nearly directly towards the player horizontally or vertically to push the player far enough in a single frame.
- This glitch tends to work better on vertical walls than horizontal floors or ceilings.
Boss Eye Despawn
While no revolutionary discoveries have been found regarding the known boss eye despawn, I determined that it is related to CPU overloading again. At this time, there are no further eye despawns that are known to be possible while utilizing CPU overloading, but it is not entirely ruled out.
Route Summary
The route has changed significantly due to the recent discoveries. This section outlines the differences in the route from the previously published TAS. Please visit the game resources page for more technical details on movement strategies and RNG manipulation.
Planet 1
The shield is collected right away because it is necessary to perform wall clips. This can be done fast enough to still make the warp timing window. The planet 12 warp glitch is performed to warp the player directly to planet 12. This is performed by utilizing a random enemy spawn and player bullets to control when the CPU interrupt occurs. The speed and trajectory of the bullet that interacts with the warp enemy is very important. The slower the bullet is, the more chances it has to interact with the enemy before it passes entirely over it. If the trajectory of the bullet is closer to northeast, then the bullet has more chances to interact with the enemy because it's hitbox is a square, and the diagonal is the longest span of the hitbox. The first bullet that interacts with the enemy executes the glitch 5 times. A second bullet hits the enemy normally to spawn the final warp to planet 12. Some slowdown had to be performed to ensure the planet 12 warp is the first one to move so that the player can interact with it.
Planet 12
Because planet 13 is skipped, this route has significantly less money. At the shop, only one double strength thruster is purchased. Instead of taking an intentional death, this planet will be done in one go to preserve the double strength thruster for the entire duration of the planet.
Wall clipping significantly changes the route possibilities, and 3 will be performed to traverse the planet efficiently. For each wall clip, RNG manipulation is used to spawn in the necessary amount of sphere enemies to overload the CPU. The first clip is directly northeast from the start to reach the first fuel cell and the top area quickly. The second clip is at the top on the way to dropping off the first fuel cell, which allows the player to travel to the 2 fuel cells near the center of the map. The first fuel cell can be dropped off at the top right while out of bounds, and the second fuel cell nearby can be grabbed while out of bounds and taken to the drop off point near the other fuel cells. After dropping all fuel off, a third clip is performed nearby in the underwater section to bypass nearly all of the labyrinth section and head directly to the warpship part room.
The general movement strategies have not changed, and carryable items are utilized to max out the player's velocity over the thrusting limit whenever applicable.
The warpship part room is performed without anti-gravity since that cannot be afforded leading to more challenging movement optimizations, but the overall techniques are still the same.
Final Boss
The eye despawn glitch is performed during the auto-scroller in a similar manner.
A small improvement of 4 frames was found for the boss kill. The strategy has not changed, but slightly different shooting timing yielded a faster outcome.
Timing
Criteria
I am adjusting the criteria for the splits for future consistency and simplicity with this route in mind.
For a more precise timing, the following RAM addresses are referenced:
0x003B - Current Planet Indicator (Planet 1 = 00, Planet 12 = 0B, Part Room = 18, Boss = 1A) 0x045B - Health of final eye
And the following criteria:
- Start - All the frames from power-up until the start of the first planet.
- Planet {#}, Part Room, Boss - These splits start as soon as the planet indicator changes. Since this value is initialized to 00, special case for Planet 1 which starts on the frame pressing START on the "START GAME" menu.
- End - This movie's end time is taken at the last frame before the final eye's health is zero. This criteria differs from the previous published TAS's (being the frame of the last input) so that it prevents a case where the game has not been completed before inputs have ceased which would artificially lower the time, and could encourage setups that shoot the final bullet from further away and cease inputs. This is also more indicative of the game being "completed". This timing does not affect the final time of the previously published TAS.
Time Table
Despite the route being vastly different, it is still useful and interesting to compare against the previously published TAS. All skipped segments from the previous published TAS are included in the "PLANET 1" segment since they occur between planet 1 and planet 12. All values are in frames.
|| NEW || OLD || DELTA
_ _ _ _ _ _||_ _ _ _ _ _ _ _||_ _ _ _ _ _ _ _||_ _ _ _ _ _ _ _ _ _
SPLIT || START | COUNT || START | COUNT || SPLIT | TOTAL
_ _ _ _ _ _||_ _ _ _|_ _ _ _||_ _ _ _|_ _ _ _||_ _ _ _ _|_ _ _ _ _
Start || 0 | 114 || 0 | 113 || +1 | +1
Planet 1 || 114 | 2115 || 113 | 17398 || -15283 | -15282
Planet 12 || 2229 | 13605 || 17511 | 18304 || -6699 | -21561
Part Room || 14254 | 2017 || 35815 | 1822 || +195 | -21366
Boss || 16271 | 8343 || 37637 | 8347 || -4 | -21370
End || 24614 | - || 45984 | - || - | -
Notes:
- 1 frame is lost in the "Start" split due to slower boot times on FCEUX compared to quickerNES.
Software & Hardware
ROM
- Solar Jetman - Hunt for the Golden Warpship (USA).nes
- SHA1: CAA4D1AB710BD766F8505EF24F5702DAC6E988AF
- MD5: 45757BDF0D1A0E9DE8F9590FB692DA55
Emulator
I created this TAS in FCEUX version 2.6.6, but have done some testing in other emulators and have noticed the following behavior differences:
- NesHawk appears to handle CPU interrupts inconsistently with FCEUX and quickerNES, as my TAS desyncs on the planet 12 warp when I recreate it with the same inputs in NesHawk. It behaves the same in quickerNES, however. The interrupt was observed to occur at different points in the code execution.
- FCEUX has a slower boot time by 1 frame compared to quickerNES
- quickerNES appears to handle RNG during the auto-scroller inconsistently with FCEUX and NesHawk, as my TAS desyncs during that section when I recreate it with the same inputs in quickerNES. It behaves the same in NesHawk, however. The RNG byte at RAM address $5A was observed to desync.
It will be interesting to see if/when this TAS desyncs during console validation. The previously published TAS was documented as being created in NesHawk, although it is possible that differing CPU interrupt behavior does not cause a desync if it is not being abused. At this time I am unsure which emulator is most accurate for this game.
Acknowledgements
Thank you to Zericc for welcoming me to the community and teaching me about the game and it's history. Thank you to ktwo, eien86, and FatRatKnight for their work on previous published TASes, publishing technical documentation, and guidance. A very special thank you to my Bean_of_Truth for encouraging me, bringing my ideas to life in his speedruns, and being the best brother.
Samsara: Claiming for judging.