Submission #5266: Alyosha's NES Cybernoid: The Fighting Machine in 04:39.02

Cybernoid is a rather short platformer / shooter where you have to pilot your ship through various obstacles and enemies to reach the end of 3 levels. The game is known for its difficulty as your ship only gets one hit and enemy behaviour has a lot of randomness.

While not that interesting in terms of gameplay, this game is notible for the fact that it leaves several RAM values uninitialized that effect the game. There are two effects. One is sound. The game has two sound modes, one is for 'advanced' sound effects, the other has music. Bit 0 of 0x05FB controls the sound mode. The other is initial difficulty setting on the main menu. This is controlled by the lower 2 bits of 0x0523 and is also unintialized at startup. You can see evidence of these things in online videos and guides where there is a bit of confusion over what sound mode is the default.

With BizHawk 1.11.8, we now have the ability to set power up RAM. So I did so to set the initial menu setting to hard mode, and turn on sound. For this run all RAM is set to zero except for 0x0523 which is set to 2 (Lethal difficulty selected) and 0x05FB is set to 1 (music on.)

It should also be noted that RNG is effected by uninitialized RAM as well, but there is no obvious beneift to having one RNG state over another, only having lethal difficulty selected actually saves any frames (4) compared to the published run.

I also saved more time with better optimized gameplay. In level 1 I also took the opportunity to show off the transformation balloon, you can see it float across the screen as the ship hits the elevator. This would transform you into a powerful robot for the next level, but unfortunately it wasn't faster because the timer at stage end counts down slower as the robot for some reason. To get the balloon to appear you have to 1. use up all your bouncers and 2. shoot the panel on the left side of the elevator. In level 3 there is an extra death abuse which saves about 1 second.

I'm really excited to have this run on the workbench. I'll be interested to see where RAM initialization can be used more extensively in other games, but I think this is a good one to break the ice.

I need to give a big thanks to adelikat for adding the RAM initialization feature into NESHawk.

Samsara: It's been a while since I've had to make a decision everyone disagrees with.

Samsara: File replaced with a roughly 1 second faster run.

Samsara: Dropping this as I know I won't have a decision made anytime soon.

Noxxa: Claiming for judgment.

Noxxa: After much deliberation, I am going to reject the notion of starting from an arbitrary RAM state at this point in time. It is a complicated subject, and we are not ready to accept runs of this sort yet until more research is done.

Right now, we have an arbitrarily input RAM state, which has much greater odds than not of being an illegitimate starting value of unmodified NES hardware. The effects of the three bits specifically set in this movie are known to occur on console, but the legitimacy of the rest of the RAM configuration is unknown. This rest of the RAM configuration is still significant, as modifying it turned out to affect movie sync. To keep things manageable, we'll require that RAM states are valid in their entirety, without having to figure out exactly which bytes could be disregarded for movie sync and which could not.

So, the next question is how to determine what starting RAM states are valid. This page lays down some mathematics for it, but we will need more research still (I'd like to encourage anyone interested in this subject to create a new topic for that). If the logic of how the RAM is filled is known, then it would be possible to determine all possible valid RAM states - and if a movie such as this one could be made with exactly one of these possible RAM states, then it would be acceptable. But until more research is done on what possible RAM states are valid, we are not ready to accept runs of this sort yet.