Submission Text Full Submission Page
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.

Game objectives

  • Emulator used: BizHawk 1.11.8
  • Beats the game as fast as possible
  • Saves time by initializing RAM
  • Plays on hardest difficulty

Comments

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.

Special Thanks

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.

Show more

Hide
1 2
Posted: 10/25/2016 7:50 AM
Quote
andypanther
Any
Former player
Joined: 6/30/2010
Posts: 1094
Location: Zurich, Switzerland
I don't understand enough of this stuff, can anyone explain the difference between this TAS and the published Cheetahmen II TAS by adelikat? Thanks.
Current project: Gex 3 any% Paused: Gex 64 any% There are no N64 emulators. Just SM64 emulators with hacky support for all the other games.
Posted: 10/25/2016 11:17 AM
Quote
Patashu
He/Him
Joined: 10/2/2005
Posts: 4017
andypanther wrote:
I don't understand enough of this stuff, can anyone explain the difference between this TAS and the published Cheetahmen II TAS by adelikat? Thanks.
My understanding is that the Cheetahmen II TAS has been proven to be able to happen on an unmodified NES (Just by resetting it enough times until it happens that way), whereas this TAS does not have similar proof, we just have to take it by faith that the RAM used for this TAS COULD maybe happen at startup.
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
Posted: 10/25/2016 2:41 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11272
Location: RU
NES TAS of 2011
True, I'm not introducing this new policy, as I have no authority for that. I'm just trying to resolve the questionable parts of the idea. I'm not even exactly defending the approach I'm coming up with. Right now, we have this emulator ability, and a chance that using ROM swaps on console, the RAM could be tweaked. Even 1/100 is a decent chance. We know that we can't achieve arbitrary RAM states just by using a specific console or by resetting. The earlier thread I linked shows that people don't mind some sort of preset RAM state. The particular scenario we're dealing with here, wasn't discussed back then, so probably they would react differently this time. I think after this movie is judged, we could make a summarized post there, addressing this submission's problems, and discuss this altogether again.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 10/26/2016 12:54 AM
Quote
True
Editor, Player (68)
Joined: 1/18/2008
Posts: 663
andypanther wrote:
I don't understand enough of this stuff, can anyone explain the difference between this TAS and the published Cheetahmen II TAS by adelikat? Thanks.
I thought I replied to this, but I guess I fell asleep before posting. In Cheetahmen II, a single mapper register is being set to an arbitrary value. In this run, NES RAM is being set to an arbitrary value. In the former, I don't particularly agree with the submission, and had anyone else posted it, it may not have been accepted. But still, this mapper is not as well understood at the physical level, and it has been demonstrated to have this effect on console. In the latter, NES RAM can also have arbitrary state, but there are 2^16384 possible startup states. Some are far more likely than others, with the most likely on average being that of zero bits set. The difference is that of one settable register on hardware that is on the cart (8-bit register?), to three specific bits set and all others cleared out of 16384.
true on twitch - lsnes windows builds 20230425 - the date this site is buried
Posted: 10/26/2016 4:33 AM
Quote
Personman
Other
Joined: 4/20/2008
Posts: 465
The fact that cart swapping is nondeterministic, which I did not realize, changes my opinion on this, I think. It's not a great solution, because there are real runs that really do take advantage of uninitialized RAM, but maybe when faced with drawing a truly arbitrary line about unknowable probabilities, we have to just accept that TASes exist to some degree in a realm of abstraction, and declare that we are interested primarily in running the game in its purest starting state, with RAM initialized to 0. It might occasionally be pretty interesting to have a run that does rely on uninitialized RAM, in which case we could consider allowing an "arbitrary starting RAM state" branch. Any attempt to choose a "reasonable" number of bits we are allowed to flip should really be avoided – we will inevitably be presented with a run whose time scales down linearly with the number of bits we can flip, and whatever line we've picked will be very unsatisfying. My concrete preference, at this point, is: The default branch always begins from zeroed out RAM. On a case-by-case basis, "arbitrary starting RAM state" submissions can be accepted to Moons, much as we do with "game end glitch" runs. We never draw a distinction between runs based on the number of bits they flip, unless that number is 0.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Posted: 10/26/2016 3:26 PM
Quote
Alyosha
He/Him
Editor, Expert player (3534)
Joined: 11/30/2014
Posts: 2732
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
True wrote:
The difference is that of one settable register on hardware that is on the cart (8-bit register?), to three specific bits set and all others cleared out of 16384.
Actually half the RAM is explicitly cleared (0-0x400) at startup, and most of the rest is properly initialized by loading values from ROM, so it's not 3 out of 16384, more like 3 out 16-20 (for whatever RNG bits that I haven't had time to track down.)
Personman wrote:
The default branch always begins from zeroed out RAM. On a case-by-case basis, "arbitrary starting RAM state" submissions can be accepted to Moons, much as we do with "game end glitch" runs. We never draw a distinction between runs based on the number of bits they flip, unless that number is 0.
Personally I don't like framing anything in terms of moons-vault since I would hope to see that distinction removed someday, so I hope whatever decision is made can avoid that, but that being said, doing things on a case by case basis seems fine to me, not much point trying to frame a sweeping policy on what might amount to a small handful of runs overall. Also please replace the submission file with this one: http://tasvideos.org/userfiles/info/34501518718338775 I'll also updates the submissio ntext a bit to clarify what RAM is set to.
Posted: 10/27/2016 2:28 AM
Quote
True
Editor, Player (68)
Joined: 1/18/2008
Posts: 663
Alyosha wrote:
Actually half the RAM is explicitly cleared (0-0x400) at startup, and most of the rest is properly initialized by loading values from ROM, so it's not 3 out of 16384, more like 3 out 16-20 (for whatever RNG bits that I haven't had time to track down.)
That is the game doing that though. Do we track the possible entropy on a per-game basis then, based solely on RAM access? And what if something is missed, like the initial submission? This gets us back to odds. Do we play odds, or just run against an ideal console, considering that the more bits are set, the less probability of the state being correct?
Personman wrote:
The default branch always begins from zeroed out RAM. On a case-by-case basis, "arbitrary starting RAM state" submissions can be accepted to Moons, much as we do with "game end glitch" runs. We never draw a distinction between runs based on the number of bits they flip, unless that number is 0.
Alyosha wrote:
Personally I don't like framing anything in terms of moons-vault since I would hope to see that distinction removed someday, so I hope whatever decision is made can avoid that, but that being said, doing things on a case by case basis seems fine to me, not much point trying to frame a sweeping policy on what might amount to a small handful of runs overall.
Somewhat agree, but if we go this route, _what the case must be_ and why it is a valid exception is what needs to be determined now.
true on twitch - lsnes windows builds 20230425 - the date this site is buried
Posted: 10/27/2016 2:58 AM
Quote
Samsara
She/They
Senior Judge, Site Admin, Expert player (2122)
Joined: 11/13/2006
Posts: 2794
Location: Northern California
Homebrew TAS of 2023 Exotic platforms TAS of 2020 Sega TAS of 2016
Alyosha wrote:
Also please replace the submission file with this one: http://tasvideos.org/userfiles/info/34501518718338775
Done.
TASvideos Admin and acting Senior Judge 💙 | Cohost
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Posted: 10/30/2016 1:11 PM
Quote
Nicos
Joined: 6/4/2009
Posts: 893
the unitialised ram thing is a pretty shaky thing as it's a hardware related thing and not a software one (the bits are not set by the game but by the console state) if my memory is correct; setting the ram value before a run as aleady been done with the FF TAS run at A/S GDQ XX ( i don't remember the year but i remember the setup ) so the real question is if the ram need a special state before playing the run ( differ for the default patern used by the emulators) , should we count the ram modification setup in the timing ? and how would we be able to time the modification lenght ? it would set a solid ground and allow ram modifcation without penalizing the default rams runs.... ram thing aside, this run is good and it improve the published one by ~7sec so based on that, i'll give it a yes
Posted: 11/6/2016 5:52 AM
Quote
hopper
Joined: 11/15/2004
Posts: 804
Location: Canada
I agree that initializing the RAM other than the way it would be initialized on a console is like using a Game Genie code. This run is not console verifiable. Do we want to have "emulator-only" runs? And if you can do that, where does it end? Can you put arbitrary code in RAM that will cause the game to instantly jump to the victory screen?
TASing or playing back a DOS game? Make sure your files match the archive at RGB Classic Games.
Posted: 11/6/2016 9:18 AM
Quote
Patashu
He/Him
Joined: 10/2/2005
Posts: 4017
hopper wrote:
I agree that initializing the RAM other than the way it would be initialized on a console is like using a Game Genie code. This run is not console verifiable. Do we want to have "emulator-only" runs? And if you can do that, where does it end? Can you put arbitrary code in RAM that will cause the game to instantly jump to the victory screen?
It IS console verifiable - but possibly not on all NESes? Consider from the submission notes: "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." If true, then the startup state used for this TAS exists for at least some NESes. If it didn't, all guides/videos would agree on the default settings.
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
Posted: 11/6/2016 1:18 PM
Quote
Alyosha
He/Him
Editor, Expert player (3534)
Joined: 11/30/2014
Posts: 2732
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
As a side note to what patashu said , the site already does have runs that rely on the initial ram state to sync , specifically monopoly and clue . Monopoly in particular is not very likely to sync on console due to nature of fceux initial ram pattern. On the other hand , there are some games that won't boot properly assuming a ram state of all zeros , which I guess would be the nominal state. These are a couple of camerica multi-cart games. As someone who likes things to be console verifiable I admit this is messy, but I guess that's the physical world for you.
Posted: 11/6/2016 1:33 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11272
Location: RU
NES TAS of 2011
I'd also remind that we've been relying on not-proven-to-be-possible initial RAM state for NES for years (and will be, for FCEUX runs).
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 11/12/2016 11:26 PM
Quote
TASVideosGrue
They/Them
Joined: 10/1/2008
Posts: 2739
Location: The dark corners of the TASVideos server
om, nom, nom
Posted: 11/12/2016 11:35 PM
Quote
feos
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11272
Location: RU
NES TAS of 2011
Moth, could you comment on the setter cart concept as well?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Posted: 11/12/2016 11:46 PM
Quote
Alyosha
He/Him
Editor, Expert player (3534)
Joined: 11/30/2014
Posts: 2732
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
Also, what RAM state should I use to submit a run of this game? Are we just sticking with the default FCEUX state? Should I use all zeroes? There still has to be something in RAM at startup.
Posted: 11/12/2016 11:46 PM
Quote
Noxxa
They/Them
Moderator, Expert player (4140)
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
Exotic platforms TASer of 2018 Exotic platforms TAS of 2018 Exotic platforms TASer of 2017 Exotic platforms TAS of 2017 Exotic platforms TAS of 2017 Exotic platforms TASer of 2016 Exotic platforms TAS of 2016 Gameboy TASer of 2013
feos wrote:
Moth, could you comment on the setter cart concept as well?
I agree with True on this one. This basically entails running arbitrary code as a part of the movie, which would count in practice as an external modification, which we do not accept.
Alyosha wrote:
Also, what RAM state should I use to submit a run of this game? Are we just sticking with the default FCEUX state? Should I use all zeroes? There still has to be something in RAM at startup.
We can accept either the default starting state of the emulator (hard to stop accepting these after 10+ years, and we at least know it to be a standardized and unbiased state; future versions of FCEUX/BizHawk should standardize to a known valid state), or an arbitrary known valid state (which are yet to be researched/figured out).
http://www.youtube.com/Noxxa <dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects. <Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits <adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
1 2