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: 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.
To get a better idea of what kind of impact this would have, I decided to look at a number of NES games and see which access uninitialized RAM.
I modified Bizhawk slightly to monitor the RAM usage. If the game read from a RAM address before it has written to it, I recorded that. I also recorded what addresses were written to.
I took a list of NES games that the site has movies for, ran them for 600 frames each in that modified Bizhawk, and then outputted the data collected. I then turned the data into images to make it easier to digest the information.
Here is the image set (warning: large/long images)
Each 8x8 pixel block represents a RAM address, starting at 0x0000 at the top left, and ending at 0x07FF at the bottom right. The colors mean the following:
Black - RAM was not read from or written to (still uninitialized)
Green - RAM was written to first
Red - RAM was read from before it was initialized, and still hasn't been written to (still uninitialized)
Orange - RAM was read from before it was initialized, but has since been written to
Keep in mind that this data is from only 600 frames of the game, and with no input. The results may change if input is given or the analysis is run for longer.
You can tell from the images that a large number of games access uninitialized memory, but I'm not sure what they are doing with it. As other people have said, some games start up in a different way depending on the initial state of the RAM. Being able to control this initial state might be beneficial to movie authors, but I'll leave that up to other users who know more about each game to determine. This data was simply to get an idea of how many games might be impacted by this new policy.
Also, if anyone is interested in seeing my changes to Bizhawk or the raw data I made the pictures from I'll be happy to post it.
Though, I only remember one game that can be improved using this feature: Friday 13th.
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.
Please keep in mind, that as an SRAM, NES memory will have almost all bits cleared at power-on. On real-console tests, those that are set are usually at the beginning of the memory for some reason. Obviously, others can change per Alyosha's comment, but it's rare for more than two bits to be set.
Playing with memory is a sort of meta-gaming, doesn't involve user input, and in general, shouldn't be allowed as a published movie per the goals of this site. But emulators need to improve as well - the default FCEUX memory values are completely inconsistent with what a console will actually have. This is a neat experiment, regardless.
The fact that this movie initializes all of RAM with a pattern, and a real SRAM wouldn't work that way, should be reason enough not to accept. This movie is akin to using a game shark code, that affects all of memory and only before startup, I guess.
Now, should preset / uninit values be allowed? Perhaps, but I would suggest that if so, only those that have actually been observed.
In the case of consoles with PSRAM or DRAM, or with the default state of CPU registers on some architectures, it isn't so clear. But for NES, it is.
What are the actual values written in this run?
Right, I remember discussing this with adelikat on IRC some time ago, when he was about to add this feature, and his opinion (and mine too) is that such runs shouldn't be obsoleting the ones that don't manipulate startup RAM. Because it won't be a fair competition, after more than a whole decade of not using this in TASes.
Technically though, this would be equal to running a self made ROM that sets the values we want to the pattern we wish, and then injecting the actual game we'll be playing. Not a gameplay thing either, so yeah, this adds some cheating fur to the concept, even though it's not exactly that. So to make things clear and consistent, we shouldn't obsolete the old style (gameplay based) 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.
The initializing values are:
FF,FF,FF,02,FF,FF,FF,FF,FF,FF,FF,01,FF,FF,FF,FF
Repeated across all of RAM.
The other bits at the actual addresses at issue, 0x05FB and 0x0523 don't matter since the game explicity ANDs them with 1 and 3, so this run is basically setting 3 bits.
Now if you say I should be using 00 instead of FF I can certainly do that too, or even set all of RAM to 00 except the 2 addresses I explicitly need to, maybe that would be less controversial.
Right, I remember discussing this with adelikat on IRC some time ago, when he was about to add this feature, and his opinion (and mine too) is that such runs shouldn't be obsoleting the ones that don't manipulate startup RAM. Because it won't be a fair competition, after more than a whole decade of not using this in TASes.
Why would it not obsolete the existing run? Start up RAM is already manipulated with the default RAM setting, it's just that that manipulation was consistent until now. To me it seems like just adding another variable to optimize (while still being physically reasonable of course, as True points out.)
Having played this game before, I had no idea it had music! How bizarre. The version I'm used to just plays a droning sound wave. If I understand correctly, music is only enabled if an uninitialized value in memory happens to be set to 1?
Regarding the run, I've no idea what difference Hard mode makes, but this looks like a well-optimized run. Nice work!
As for preselecting memory, we have to set startup RAM to something. As long as Vault runs don't use extraordinarily unlikely setups (making their hardware reproducibility problematic), I don't really care.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Most SRAM is typically 0x00 when powered. NES is like this.
The bits that are set usually aren't random - a strongly associated per-console characterization can be performed. Certain consoles will have certain bits that they like to set, and probabilities of being set dependent on temperature, noise on the power supply, and so on.
As such, even if you changed just those three bits to being set (which isn't an unreasonable count), it is still TASing the game on a specific "characterization" of a specific console. Rather than running the spirit of the game, as it would play with the cart, you're running the game as if it were played in one very specific console that just happened to have the correct luck-of-the-draw from the fab. This luck, unlike luck in games, isn't one within our control _at all._ Unless you want it to be in an emulator, but good luck probing your SRAM with a teensy metal pointer in your console. (Is that valid input?)
This is my opinion: I believe is, as a site that puts emulators on a pedestal above actual console input, and as a site that favors perfect play, we really should TAS against an "ideal" (as close to perfect) emulation of a console as we can. Also, the typical goal of an emulator is to emulate a system as perfectly as possible, within resource bounds. This view is confirmed by this site by the obsoletion of emulators with poor emulation quality as new, more ideal emulators have been written.
Derakon wrote:
As for preselecting memory, we have to set startup RAM to something. As long as Vault runs don't use extraordinarily unlikely setups (making their hardware reproducibility problematic), I don't really care. (emphasis mine)
But I do care, because an NES is biased to having its SRAM completely cleared. An NES with a perfect SRAM chip should, at power-on, have zero bits set high.
Having played this game before, I had no idea it had music! How bizarre. The version I'm used to just plays a droning sound wave. If I understand correctly, music is only enabled if an uninitialized value in memory happens to be set to 1?
Well you can enable music manually by pausing with Start and then toggling between music and sound effects with A. But yes the game never writes to the address before reading from it to chekc what mode it's in, so if you didn't know you can change the setting you'll be stuck with the droning sound (if that's what your console favors.)
I just tried to initialize only the 2 variables I initially mentioned and set everything else to 0, but the run then de-synced and I don't know why. So, looks like there are other uninitialized factors at play here that I wasn't aware of.
Is it the opinion of people like True that all TASes on tasvideos.org should begin with all values of SRAM initialized to 0x00? Or are certain other patterns also acceptable for a submitted TAS?
I just tried to initialize only the 2 variables I initially mentioned and set everything else to 0, but the run then de-synced and I don't know why. So, looks like there are other uninitialized factors at play here that I wasn't aware of.
Makes me wonder how much of this game uses uninitialized memory now.
Is it the opinion of people like True that all TASes on tasvideos.org should begin with all values of SRAM initialized to 0x00? Or are certain other patterns also acceptable for a submitted TAS?
No, not all TASes. This is about NES specifically.
SNES, for example, uses a PSRAM. The contents at power-up are generally random. Specific patterns may be characterizable to a console, but I don't know this for sure, and anyway, each power-up will still be sufficiently random that start-state may be able to be manipulated and we could consider it acceptable.
However, keep in mind that such an input is still not within the realm of what a (super)human can do given a controller and buttons on the console. So what should be acceptable in that case? I don't know...
Back to NES, FCEUX has an alternating pattern involving 0x00 and 0xFF which has been responsible for desyncs during verification. I believe it uses this pattern as a workaround for a game. An accurate emulator would be all 0.
Here's an alternate view: if a game uses uninit RAM to initialize an RNG seed, should we allow bit setting then? If so, which ones? Most NES will have some bits set... but no guarantee as to which ones or how many. And it's possible (and ideal per the technology in use) to have none set. Dumps I have seen usually have the most random bits set near the beginning of the range. Do we only allow it around there? Do we test consoles to see what has been seen "in the wild" and replicate that? We're then back to not TASing a game, but a specific game+console... and again, the ideal console has none set. Do we ignore the ideal then, as we ignore inputs that actually sync on console but don't have an emulator equivalent?
I would argue, to have a solid foundation that closely resembles the ideal console for which we emulate, that NES runs should have cleared RAM at start. This should be the norm for which exceptions are raised, rather than a more likely unrealistic scenario of per-TAS startup RAM configuration. Such a rule would not be dissimilar to dirty save RAM - we don't allow dirty save RAM unless there is an exception (like a setup movie).
Why would it not obsolete the existing run? Start up RAM is already manipulated with the default RAM setting, it's just that that manipulation was consistent until now. To me it seems like just adding another variable to optimize (while still being physically reasonable of course, as True points out.)
Because if something is truly random (which bits real consoles set occasionally), you can't rely on it to make site rules. You can't set limits to usage of some technique that would be sane to us and non-arbitrary, if it's based on true randomness, and we can't be sure setting bit #9000 is possible at least on one particular console, or on none of them. We could run a test rom that freezes and shows the startup values, but we can not test 100% of the actual consoles, so our statistics won't give the guarantee it can't happen otherwise. That would still be nice to run such a test, to determine what is more likely to happen, but that's still unreliable to setup a new site policy after that.
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.
I think runs like this can be accepted as obsoletions without much fuss. TASes are full of things you'd need the equivalent of a "teensy metal pointer" for without an emulator - L+R, N64 joystick values you can't push a physical stick to, heck, even autofiring at 60fps is not something achievable on a real console without extra electronics.
Now, we are concerned with validity at some level. We don't want to just arbitrarily change our emulators so that the games appear to be faster. But this does not hit that restriction. An NES doesn't need to have just been powered on to play a game. We can, as feos pointed out, put in our own cart and set them to whatever we'd like. Just like we can plug in our own controllers that can produce the full range of joystick values and autofire.
Trying to define a "reasonable" number of nonzero preset RAM values is a fool's errand. Observing a few NESes a few times won't tell us anything about what's possible on every model at every temperature, and even if we can observe general trends, no one will ever prove that particular unlikely starting state is actually impossible, or probably even that a reasonable seeming one is possible. This approach is fundamentally flawed and will satisfy no one. Imagine a movie where each bit you can set saves around five seconds, but also, the further from the beginning of RAM the bit you choose, the more frames you can save. Who will decide where to draw the line? What if, a month after the line is drawn, someone claims to have observed an NES start up with a bit set further into RAM than anyone had seen previously?
Much better to accept that one of the tools that can assist us is custom carts that set RAM to whatever we want.
If this leads to some really degenerate runs, that game can always have a 'doesn't preinitialize RAM' branch in Moons.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Drawing a reasonable line is indeed impossible with all this statistical instability. But if we just allow the "special cart that presets the values" scheme, that would result in no limits to the technique whatsoever, unless that's an address the game can not write to. That way you could set up some heavier exploits than we used to have, or even inject a payload directly into RAM, but still, that would be a cheap advantage over all the existing runs. No one wants cheap challenges that aren't justified. Probably being a Vault run could justify that though.
Anyway, we had a whole thread about this already. And looking at it, I see that Vault allowing this technique is something people are okay with.
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.
I think runs like this can be accepted as obsoletions without much fuss. TASes are full of things you'd need the equivalent of a "teensy metal pointer" for without an emulator - L+R, N64 joystick values you can't push a physical stick to, heck, even autofiring at 60fps is not something achievable on a real console without extra electronics.
Every one of these examples may not be achievable with stock hardware, true. But some are. Even if they were not, every one of these examples uses a user-accessible interface. Working RAM in an NES has no such interface for the end user.
This is a thread about an NES movie. No "teensy metal pointer" is needed for arbitrary human input on this console. Let's keep the discussion with NES in mind.
Personman wrote:
Now, we are concerned with validity at some level. We don't want to just arbitrarily change our emulators so that the games appear to be faster. But this does not hit that restriction. An NES doesn't need to have just been powered on to play a game. We can, as feos pointed out, put in our own cart and set them to whatever we'd like.
First, yes, this is an arbitrary change.
Second, no, we can't put in a "setter cart" unless we use a toploader, or unless we modify our console. Front-loading NES has 10NES which will prevent a cart swap, as doing so will put the console into 1Hz reset.
What you are proposing would either require modifying the game or running arbitrary code before the game. In this case, shouldn't we TAS the modified game? Or, should the TAS instead start with the setter cart and do a swap? And wouldn't _either of these situations_ then be against site rules?
Runs that sync on console are already not allowed to be submitted here if they don't also run in an emulator. If you really want to go the setter cart route, then the emulator must support this as well. A movie utilizing this technique should consist of running multiple ROMs and allow cart swaps within the movie file.
Simply setting arbitrary RAM is not the same as your setter cart idea. I can't arbitrary set RAM on an NES unless I run my own code. The setter cart, as I have used to sync some NES games, is a workaround to flaws in emulation, such as FCEUX's completely invalid startup memory state.Personman wrote:
Just like we can plug in our own controllers that can produce the full range of joystick values and autofire.
The controller is using a standard protocol. In the case of NES, there isn't much to it. This discussion is about NES.
The cartridge slot, on the other hand, is a direct connection to the CPU and PPU buses, and to 10NES in the front-loader. This usually isn't user-accessible during play. One puts in a cart, powers the console, and keeps the cart in during the entire play session. 100% of NES runs submitted to this site make this assumption. Also, this slot isn't hot-swap safe. I've made it work on a toploader by holding the console in reset during the swap, but even then it isn't reliable.
Personman wrote:
Trying to define a "reasonable" number of nonzero preset RAM values is a fool's errand. Observing a few NESes a few times won't tell us anything about what's possible on every model at every temperature, and even if we can observe general trends, no one will ever prove that particular unlikely starting state is actually impossible, or probably even that a reasonable seeming one is possible. This approach is fundamentally flawed and will satisfy no one.
This is exactly what I was arguing. The only sane choice would be running against an "ideal" NES, with case-by-case exceptions. It is these exceptions that need to be worked out and have not yet been.
An "ideal" NES will have no bits in working SRAM set at power on.
Personman wrote:
Much better to accept that one of the tools that can assist us is custom carts that set RAM to whatever we want.
Why should this allowed, but dirty save RAM is not?
feos wrote:
But if we just allow the "special cart that presets the values" scheme, that would result in no limits to the technique whatsoever, unless that's an address the game can not write to. That way you could set up some heavier exploits than we used to have, or even inject a payload directly into RAM, but still, that would be a cheap advantage over all the existing runs. No one wants cheap challenges that aren't justified.
If we're talking of a memory setter cart, why stop at just setting memory? That seems awfully arbitrary?
Most movies published on TASVideos are runs against commercial games. If the game was not commercial, it typically must be notable or "entertaining" to be published.
If we went with the setter cart idea, would the setter cart ROM need to be entertaining or notable? Would TASing commercial titles requiring a homebrew memory setter, running arbitrary code not related to the title being run, seem fair? That's what this setter cart thing is getting to.
feos wrote:
Anyway, we had a whole thread about this already. And looking at it, I see that Vault allowing this technique is something people are okay with.
I'm OK with accepting input files that sync on console to the site. If I make a thread discussing that and others agree, does that make it submittable?
Some of the technical information in the thread you linked does not apply to NES, such as information about DRAM or small process node SRAM startup and decay states. Some of this incorrect information was posted by a user who shares my view. This shouldn't be a crowd-sourced decision, as it is a very technical one and the correct information should be presented before reaching any consensus or conclusion.
feos, this specific run uses a runner-chosen initialization value that is, in all likelihood, _statistically impossible_ to achieve on console. Where is the line drawn? Perhaps that's the more important question.
Are we moving from tool-assistance (tools are used to create a run) to tool-dependance (tools are required to play the run)?
feos, this specific run uses a runner-chosen initialization value that is, in all likelihood, _statistically impossible_ to achieve on console. Where is the line drawn?
That's an important note. As I said, if we can't know for sure that something is possible, we can't rely on it in the policies. But elaborate, is this exact RAM state achievable with the setter cart (given we're using a toploader NES or Famicom AV)? To me, if it's possible, it looks like a dirty SRAM movie that uses a verification movie to achieve that SRAM, and that movie doesn't have to be optimal, it should just be valid. But if such a cart could set any addresses to anything, then ROM switching isn't required, the emulator could just preset those directly.
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.
I can certainly see where the initial vector for initializing RAM I used is non-physical based on what True said, so I will re-sync this run to one where all of RAM is 0 except the 3 bits I purposely set (well it's actually 2 bits that are set to 1)
RNG is usually just a matter of pressing select until you get what you want, so it should be done later today. I'm a bit surprised the run de-synced since I was quite certain I looked at RNG before and concluded it wasn't impacted by uninitialized RAM, but it's possible I just made a mistake since I didn't have the tools back then to easily check like now.
Anyway I guess my opinion would be that it's fine to deviate a bit from 'ideal' NES behaviour so long as it doesn't venture into the realm of statistical impossibility. Where to draw the line? Only a certain number of bits can be set maybe? Maybe that can only be decided when more such runs are submitted.
EDIT: And here it is:
http://tasvideos.org/userfiles/info/34501518718338775
Please replace the movie file with this one. As stated it only sets 0x523 and 0x5FB to nonzero values. I also saved a few frames along the way with another death abuse, so that's good too.
That's an important note. As I said, if we can't know for sure that something is possible, we can't rely on it in the policies.
This is not how current policies here are formed. Besides, the memory set on the run before, as arbitrarily specified, is statistically impossible. Because it is just statistics, and not hard impossibility, if such reasoning was followed, then are we truly TASing the game then as it is expected to be run, or just some imaginary arbitrary setup of it?
feos wrote:
But elaborate, is this exact RAM state achievable with the setter cart (given we're using a toploader NES or Famicom AV)? To me, if it's possible, it looks like a dirty SRAM movie that uses a verification movie to achieve that SRAM, and that movie doesn't have to be optimal, it should just be valid.
Yes, it is possible. But here's some differences from simple dirty save RAM:
- In dirty save RAM, the same game that is being played is also used in verification. In this case, completely different code is run. The code created is arbitrary and created by the user or verifier.
- As the code is different, this implies carts have been swapped. Are cart swaps now allowed? If so, should the emulator support this?
- Such a ROM can do far more than set memory. It's rather arbitrary to draw the line at just setting memory. Do we only allow certain instruction sequences to accommodate for an emulator's settings?
- If our goal is to TAS games, and not specific emulations of games, then why would the actual game on console as originally released come second to the game emulated?
feos wrote:
But if such a cart could set any addresses to anything, then ROM switching isn't required, the emulator could just preset those directly.
This doesn't make sense, based on everything else written; can you clarify? Because for what we've written, on a console, ROM switching would be required to match an unlikely starting state arbitrarily specified in the emulator.
But if such a cart could set any addresses to anything, then ROM switching isn't required, the emulator could just preset those directly.
This doesn't make sense, based on everything else written; can you clarify? Because for what we've written, on a console, ROM switching would be required to match an unlikely starting state arbitrarily specified in the emulator.
I mean an emulator feature to switch ROMs isn't required.
True wrote:
Yes, it is possible. But here's some differences from simple dirty save RAM:
- In dirty save RAM, the same game that is being played is also used in verification. In this case, completely different code is run. The code created is arbitrary and created by the user or verifier.
- As the code is different, this implies carts have been swapped. Are cart swaps now allowed? If so, should the emulator support this?
- Such a ROM can do far more than set memory. It's rather arbitrary to draw the line at just setting memory. Do we only allow certain instruction sequences to accommodate for an emulator's settings?
- If our goal is to TAS games, and not specific emulations of games, then why would the actual game on console as originally released come second to the game emulated?
But what could be the differences introduced by any ROM we previously run other than just memory state? If this policy is added in the way I see it, only the initial RAM state itself would matter, not what could possibly lead to it, unless we're sure such a state is impossible at all.
True wrote:
feos wrote:
That's an important note. As I said, if we can't know for sure that something is possible, we can't rely on it in the policies.
This is not how current policies here are formed. Besides, the memory set on the run before, as arbitrarily specified, is statistically impossible. Because it is just statistics, and not hard impossibility, if such reasoning was followed, then are we truly TASing the game then as it is expected to be run, or just some imaginary arbitrary setup of it?
First, I meant the potential new policy, to handle such runs. Second, if it is reproduce on console without (the traditional meaning of) cheating, we could allow it.
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.
how would the initial ram be created in a reproduction on console?
A cart with a ROM on it that just sets those values and is then replaced with the actual game cart.
True wrote:
feos wrote:
But elaborate, is this exact RAM state achievable with the setter cart (given we're using a toploader NES or Famicom AV)? To me, if it's possible, it looks like a dirty SRAM movie that uses a verification movie to achieve that SRAM, and that movie doesn't have to be optimal, it should just be valid.
Yes, it is possible.
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.
My question, entirely unrelated to the setting of RAM beforehand, is why you use abilities with no result early in the run (0:24, 0:35), and why you fire one Bomb too many at around 4:08 - there's nothing in the way, you just launch an extra Bomb into the wall for no apparent reason.
I am still the wizard that did it.
"On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart, I am a gamer." -- Satoru Iwata
<scrimpy> at least I now know where every map, energy and save room in this game is
I mean an emulator feature to switch ROMs isn't required.
But if the end effect is that this is required anyway, why would this specific method get a pass, when actual console input is not submittable until an accepted emulator supports the format "natively?" (because, as I understand it, the input in an interpreted code format, versus a file->open format, is currently not allowed)
feos wrote:
But what could be the differences introduced by any ROM we previously run other than just memory state?
- Bus errors during swap causing a freeze, or worse, other undefined behavior, such as but not limited to:
- Register states possibly being different
- Mapper registers or states possibly being glitched by hot insertion
- Different DMA cycle alignment
The console was not designed for swapping carts while powered on. Just because it can, doesn't mean it works every time or is deterministic. My Final Fantasy verification YouTube video took about three dozen takes before I got the two swaps to work successfully.
feos wrote:
Second, if it is reproduce on console without (the traditional meaning of) cheating, we could allow it.
What is the "traditional" meaning? And why do traditions matter for "cheating," but not for the arbitrary execution of code before the game even starts or tainting of memory?
In fact, traditions have given us things like the completely wrong FCEUX startup memory state.
But would running arbitrary code at startup entail "cheating?"
grassini wrote:
how would the initial ram be created in a reproduction on console?
feos wrote:
A cart with a ROM on it that just sets those values and is then replaced with the actual game cart.
And yes, this is what it comes down to - arbitrary code needs to run to set the bits necessary to make this run sync.
----
Certain given states may be as statistically likely as the all-zero state, but only one state has the most statistically significant chance of sync in games that read and utilize before write, and that is of all bits cleared.
The NES is not designed with hot-swap carts. As much as we say "super human inputs" even for 30hz mashing, it isn't a physical impossibility of the input hardware. Swapping the cart however IS something that can't be deterministically performed, as the console was not designed for it, and in fact cannot be performed on the original version of this hardware without modification. And should we introduce a cart-swap delay? Because it can't be physically cleared and replaced in one frame or less time.
---
feos, So you are saying, cart swapping on NES is valid input now? Even though emulators don't support it, and the games and consoles were never designed nor exploited by commercial titles to do this?
Should this submission have such an arbitrary code ROM attached to set RAM, or is having the finger of God poking some bits high acceptable?
If the former, why are we allowing arbitrary code to run before the title in question? If the latter, is it not "cheating" because God does it?
As stated before, these consoles were NOT designed to hot-swap carts. To get runs with arbitrary memory values to sync on an ideal NES, either a modified game needs to be used, or a setter cart runs arbitrary code before the game is swapped in on a modified or specific version of the console. This unsafe, unsupported and non-deterministic swap is one of only two methods a human (or superhuman) can use to guarantee the specified startup state. We already know that a modified game is not allowed per site rules and "tradition."
I think you don't care about an "ideal" NES, which is a fair viewpoint. But having some arbitrary, impossible to achieve NES is not fine, either. And to have anything but the ideal would imply we must also have the impossible based on current discussion.
To go another way - if we ignore the cart swaps, then are we truly TASing the game anymore? If the discussion were to go this way, then I would heavily argue in that case that we are in fact running a particular emulation's view. The work is now a combined work of emulator and binary, rather than using the emulator as a means to an end. We know and accept that emulators are a means to an end now by porting of movies between emulators, console verification of inputs and attempts to improve emulation. But, if this swapless view is the accepted view, then the listed console when the game is submitted or published (in this case, NES) should be replaced with the emulator or core (in this case, NESHawk), because it isn't an NES run anymore at that point. Anything else in this case would be deceit.
Somewhat in jest, but also somewhat seriously: If we want perfect play, we should at least play on the perfect console, lest we play the console and not the game.
or another way: Perfection isn't omnipresent. It is but one state of multitudes.
My question, entirely unrelated to the setting of RAM beforehand, is why you use abilities with no result early in the run (0:24, 0:35), and why you fire one Bomb too many at around 4:08 - there's nothing in the way, you just launch an extra Bomb into the wall for no apparent reason.
Oh yeah I didn't explain this before. In order to get the transformation balloon to appear, you have to 1.) use up all your bouncers and 2.) shoot the box on the left side of elevator. So that is why I randomly used some bouncers. I used them a bit more carefully in the updated submission file and it looks less sloppy, so perhaps I should update the encode as well.
At 4:08 I just missed that extra shot, oops! Also fixed in the updated submission I think.
Oh, that does nicely answer the bouncer thing, thanks. I hope the bomb is fixed too, really don't want you to have to do it a third time.
I am still the wizard that did it.
"On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart, I am a gamer." -- Satoru Iwata
<scrimpy> at least I now know where every map, energy and save room in this game is
