I present to you, the first ever Cheetahmen II TAS that plays the original (not bugfixed) version AND shows the final boss!
History
Cheetahmen II was never released. Copies of this rare cart were discovered in a warehouse after the Action 52 company went out of business. It was a prototype for a sequel for the "hit" game Cheetahmen on the Action 52 cart. Not releasing this was a good decision, not only is it a terrible game, it had numerous bugs that made the game unplayable. The most significant was a bug that prevented the game from progressing after you beat the level 4 boss. While the game had 6 levels, for a long time people did not know this, due to not being able to get past level 4.
However, it was discovered that sometimes the game would start on a random level, and it was discovered that one of these was level 5! Now people could finally see the rest of the game (unfortunately for them).
The reason for this glitch is due to the fact that the board registers start off in an unpredictable state. This is a known issue in hardware, and most any board is built to clear out registers before attempting to use them. Good NES carts like MMC3 would do this for instance. Also, good games are programmed to loop and clear out ram, and set registers BEFORE attempting to use them. However, Cheetahmen II uses a custom board built by the Action 52 company and not surprisingly, this board is bad. It has no logic for clearing out these registers. Cheetahmen II is a badly programmed game, so it actually reads from mapper registers before setting them. Furthermore, in this perfect storm of crappiness, the game is built on a multi-cart board design. So it happens that each level is built on a separate PRG bank. Normally if the PRG register was set badly in a game, it would likely crash (as any program would if you started it halfway in).
Determinate indeterminacy
In TASing emulators, random register states and ram are bad things, they will cause indeterminacy and it is impossible to have a movie sync reliably. So emulators tend to program ram values to 0's, and all mapper registers as well. However, this is just one of many valid and possible start up scenarios! I suggest that a TAS can and should be able to exploit the initial state of hardware! If the all powerful superhuman that TASes represent can predict future RNG values, why can't he have full control over when to turn on the hardware to get the values of his choosing? With this in mind, I modded Bizhawk so that you can set the initial register values inside a movie file. This way we don't violate determinacy issues, while still giving full power to the TASer to control this situation. In this case of this submission, my movie file starts the game on PRG bank 11 (which is the start of level 5) with a prg mode of 1 (not terribly important detail, but needed for the game to run properly from bank 11).
Ending
After you kill the level 6 boss (or level 4 boss), the end of the level does not trigger. The "Fixed" from fixes this bug. But since an ending was never programmed into the game, it simply triggers a game over screen.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Just because various values can be random, it does not imply that every combination of values would actually occur.
We need proof that a particular start up state is indeed possible.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Site Developer, Site Owner, Expert player
(3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Pop fiction episodeSome guy performning it on a real nes
I'd love to make my own video, showing the NES too and that I'm only presing the power and showing it starts the same way as this TAS. Given the retail price of a real cart, that's not going to happen ^_^
But I think these videos are definitive, and the theory I'm using matches the behaviors demonstrated on a real cart.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
How are these videos definitive of anything? They don't prove the particular start up state you're using is valid. It only proves that one similar to the start up state you're using is.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
And perhaps some other registers or RAM are also filled a certain way when the register in question is set to what you need to here?
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Emulator Coder, Site Developer, Site Owner, Expert player
(3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Ram is irrelevant in this case, that was the first thing I assumed was happening. But changing initial ram has no effect on the game, and some debugging proved it. The game at least does a start up sequences that clears out ram on bootup.
As for other registers there aren't any of consequence if you look at the mapper document I linked. The other registers for this board are CHR banks, you can change these of course. If they have any effect it would be that the graphics would look "garbled" but the game is otherwise playable. THere is also the "chip select" to select which 256kb PRG chip to use. The 2nd chip isn't in the cheetamen II carts, only action 52. Setting this would cause the game to crash or perhaps it would simply ignore it. Then there is the mirroring register, altering this would also be a game crash.
I didn't debug mirroing, chip selection, or chr registers, but I suspect those get set before using them as I haven't seen this type of behavior in the limited videos that are on the internet. However, when debugging the game you can clearly see that it reads from PRG registers before ever setting them. The game falsely assumes those registers to be zero on start up.
Good job, adelikat, I didn't see this coming. A game as bad as this one doesn't deserve any better. It's a shame it can't be completed, though.
The question now is, if this should obsolete the published run or not. I'm, of course, not really objective in that matter as I am the author of said run. Either way, I would say it shouldn't obsolete it because it doesn't beat the game (although you can't really call the ending of the other run an "ending", it just goes back to the title screen)
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.
So, instead of emulating subframe resets to achieve the same goal legitimately, you decided to add the ability to store initial state of mapper. A quick-and-dirty solution suits the game well, sure. But, effectively, this new movie starts from a savestate, even though it doesn't initialize RAM, only mapper's registers.
According to the site rules we still need to have a verification movie (e.g. one which plays first 4 stages of the game and then resets at such a moment when mapper registers have all the necesssary values, or maybe just resets without playing any levels).
TASVideoAgent wrote:
If the all powerful superhuman that TASes represent can predict future RNG values, why can't he have full control over when to turn on the hardware to get the values of his choosing?
It's generally implied that the state of hardware doesn't change while it's powered off (at least it shouldn't be changing inside the clean sandbox conditions).
So, it's not enought to simply choose the right moment when to turn power on (when to drag the console out of the "cryo camera"). The superhuman would need to previously mess with state of the game (e.g. while recording a verification movie).
Emulator Coder, Site Developer, Site Owner, Expert player
(3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
AnS wrote:
even though it doesn't initialize RAM, only mapper's registers.
It doesn't initialize anything at all
It's generally implied that the state of hardware doesn't change while it's powered off (at least it shouldn't be changing inside the clean sandbox conditions).
This statement implies that something changed. It did not. On power on, there are many possible states the hardware could be in. Why is one of these states more valid than the other to because "the" state? Until now, to create a "clean sandbox condition" we have arbitrarily been picking a state and calling it the state at which an NES starts up in. In the case of ram it isn't even all 0's. All rerecording NES emulators use the pattern of 0000FFFF0000FFFF that start ram off in, because all 0's breaks certain games. (And this pattern breaks games too, but only obscure pirate carts).
In summary, I don't see the logic in a verification movie to verify a possible state this game could start in. It CAN start in this state! A verification movie verifies that you can start from another arbitrary state and achieve this given state by using input, I don't see what that serves here.
Hm....I remembered asking about syncing Friday the 13th for the NES, and I think someone (Brandon, I think), said that it desynced differently each time. I wonder if that game also utilizes this behavior.
Mapper's registers are saved in a savestate file, their values are part of the game/console state. Initializing these registers is the same as initializing CPU registers, which in turn is the same as initializing RAM.
adelikat wrote:
This statement implies that something changed. It did not.
OK, this is pure hardware question which is too vague to argue about.
adelikat wrote:
On power on, there are many possible states the hardware could be in. Why is one of these states more valid than the other to because "the" state?
That one state is more valid, because it's universally chosen by the community, and it applies to all games on the platform. If the community chose a 0F0F0F0F pattern, it would have to be applied to all games and TASes on the platform as well. Having a custom pattern for a certain game is possible, but it counts as "starting from savestate", because it gives you an advantage over TASes that used common pattern.
adelikat wrote:
Until now, to create a "clean sandbox condition" we have arbitrarily been picking a state and calling it the state at which an NES starts up in.
At least the state was hardcoded in emulators and was obligatory for everyone, so it created equal opportunities for all TASers. Are you suggesting that "from now" TASers can choose whatever initial state they want and thus beat old movies with movies starting from a savestate?
adelikat wrote:
In summary, I don't see the logic in a verification movie to verify a possible state this game could start in.
Then what was the reason for this rule? If there's no need for verification movies, maybe we also don't need to submit input logs, just provide a savestate for the last frame of the movie (+Youtube encode)?
Emulator Coder, Site Developer, Site Owner, Expert player
(3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
jlun2 wrote:
Hm....I remembered asking about syncing Friday the 13th for the NES, and I think someone (Brandon, I think), said that it desynced differently each time. I wonder if that game also utilizes this behavior.
Well, it is unlikely that it has to do with mapper registers, but certainly can be due to being affected by unitialized ram.
I could also support an initial ram pattern as a header line in a movie file too, if someone found one that is advantageous in this game (or any game)
I don't have any problem with the starting state manipulation.
As far as I can understand, the run technically starts from power on and an arbitrary state. It sounds like every other "power on starting" run of other games, they just have another arbitrary state that is considered a standard (mainly because of compatibility issues with the majority of games I guess). This game requires a specific, different, state to be able to see the final levels with a non hacked rom/cartridge.
I'm not good enough in technical stuff to find out if the state used here is "legit" (RAM, etc... all possible on a real NES, I mean), I only know it's possible to make the game start in a veeeeeeery similar way on real hardware.
But on the other hand, I don't know either if the default start up state used by most or all emulators is legit too ^^.
So I'll leave it to people that are more competent to understand Adelikat's explanations (and test stuff if required).
On a less technical subject, I see one thing that can be problematic: the run doesn't finish the game.
But again, it's a special case... It just can't be finished.
Here are the rules of the site about ending a game, to make it easier:
Your movie should begin from the console power-on and end when the last decisive action has been delivered. There are no specific rules for an exact endpoint but it must adhere to the following rules:
It must beat the game (1-level movies are rejected).
It must be able to reach the credits or end screen without requiring any further interaction; all input must come solely from the input file (e.g. configuring the emulator to autofire after the end of playback is not allowed). An exception has been allowed for Rygar.
It should end with the last input. Don't leave any blank input at the end of the movie.
If a game never ends, then it may be considered complete once there is no new content introduced, and the difficulty no longer increases.
But we already have exceptions to this, depending on the genre played, there are also runs that only play one part (one mode, for example) of a game.
Clearly, here, the last achievement possible is to bring the final boss to 1HP.
Sooo... Good luck for judging this run, I really can't state a definitive opinion :D
Anyway, it's technically interesting. (where is the "mad scientist" tier or category when we need it the most? Where all the weird runs could go, like the total control ones and some technical demonstrations)
I'm on adelikat's side. A game has uninitialized RAM and registers, which are in random states, before power-on. I see no reason why a TASer should not be able to pick which of these states to use.
The save-anchored movies rule is for when movies start with dirty persistent memory, like SRAM. This is not the case here. Also, as far as I know, the console only initializes the CPU registers before execution at power-on, so as long as these registers are untouched, the movie counts as starting from power-on.
I made Thread #14051: Debate: allowed or not? a few months earlier debating this very topic among others. I recommend a read.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
So here's the real question. How do we know the game can *start* in this state? Maybe it can only *reset* to this kind of state?
Think about the following scenario: The PCB initializes certain registers upon power on, but does nothing to them upon reset. The game does nothing itself when it begins. Do we have any data which proves the PCB does not initialize the registers in question?
The video above only proves it can be reset to a similar state.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Allowing TASes to start from an arbitrary state (instead of a universally accepted state) is a huge change of the site rules. It's funny that such an unentertaining TAS would be a ground for changing rules so much.
Also, I'm questioning the technical side of the original assertion.
Where is the proof that NES can start with any uninitialized RAM values? This page states that "all internal memory ($0000-$07FF) was consistently set to $ff except for a few bytes". Same goes for mapper registers - you don't know for sure if they can have those values at poweron.
Nach wrote:
So here's the real question. How do we know the game can *start* in this state? Maybe it can only *reset* to this kind of state?
Think about the following scenario: The PCB initializes certain registers upon power on, but does nothing to them upon reset. The game does nothing itself when it begins. Do we have any data which proves the PCB does not initialize the registers in question?
The video above only proves it can be reset to a similar state.
Exactly. Youtube videos only show how the registers got those values after many consecutive resets (which could mean that the needed values are written after launching the first level, or that the mapper hardware needs to undertake several consecutive surges in order to gain enough heat, or something entirely different - but it doesn't show that fresh cartridges may have these values in mapper registers by default).
Also, I'm questioning the technical side of the original assertion.
Where is the proof that NES can start with any uninitialized RAM values? This page states that "all internal memory ($0000-$07FF) was consistently set to $ff except for a few bytes". Same goes for mapper registers - you don't know for sure if they can have those values at poweron.
To quote your own source, verbatim, "Please note that you should NOT rely on the state of any registers after Power-UP and especially not the stack register and RAM ($0000-$07FF)."
Why? It is how this hardware works. Do you want to learn?
For a practical example, try replaying the fighter FF TAS on NES, and notice the first battle is almost always different. For why this is, refer to disassembly and the quoted note above.
AnS wrote:
The video above only proves it can be reset to a similar state.
Allowing TASes to start from an arbitrary state (instead of a universally accepted state) is a huge change of the site rules. It's funny that such an unentertaining TAS would be a ground for changing rules so much.
Uh....
Well, we did have this movie that ended up making the dsm contain the firmware settings. Infact, does the firmware settings for NDS movies count as an arbitrary state? There are some games like animal crossing, pokemon, rubik's world, etc that has different luck depending on when the time, name, color, etc is at power on.
Allowing TASes to start from an arbitrary state (instead of a universally accepted state) is a huge change of the site rules. It's funny that such an unentertaining TAS would be a ground for changing rules so much.
Uh....
Well, we did have this movie that ended up making the dsm contain the firmware settings. Infact, does the firmware settings for NDS movies count as an arbitrary state? There are some games like animal crossing, pokemon, rubik's world, etc that has different luck depending on when the time, name, color, etc is at power on.
The setup for the NDS case can (possibly, I don't know clock details) be deterministic. For this case, it isn't certain.
What state the RAM is in on starting up the NES isn't 'starting from a savestate'. TASes already start from an arbitrarily chosen with no physical meaning RAM state (the pattern 0000FFFF0000FFFF...) that could potentially be beneficial some games, such as Wheel of Fortune, read from RAM before initializing it to a known state, and so the initial RAM state could lead to a faster or slower fastest possible TAS). All adelikat is saying 'If this arbitrarily chosen with no physical meaning initial state is OK, I should be able to pick the state that leads to the fastest TAS'. If you question if adelikat's chosen state is possible to start on, question if 0000FFFF0000FFFF... is possible to start on - then every NES TAS on the site is in danger of rejection!
Joined: 10/12/2011
Posts: 6437
Location: The land down under.
Seeing how there are no votes I will refrain myself from voting (for the time being).
I love that you actually used the game without patches to do this run, in my opinion since it's not patched this should obsolete the patched.
I would give it Meh for entertainment to let it go to the vault... but as I stated I will wait for a vote.
lovely run.
Edit: 1 Yes, 1 No and here's my Meh.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account.Something better for yourself and also others.
I would vote no because this run fails to beat the game while the currently published run does. Although this one run uses the "original" version, that one was never released, and given that there's now an official version that is beatable, I don't see the point of using the old ROM.
However, this run is interesting if only because it tries to showcase a bug that cannot be emulated, even if it achieves this by questionable ways. Isn't this bug in the patched version? If so, you would have a TAS that is both faster and beats the final boss.
I would vote no because this run fails to beat the game while the currently published run does. Although this one run uses the "original" version, that one was never released, and given that there's now an official version that is beatable, I don't see the point of using the old ROM.
This "original" version WAS released. It also runs an easy $500-700+
The "Official" version done via Kickstarter was literally a patched version that allowed all the levels and the final boss to be beaten, but far from being an official release.. or at least in the context that collectors would classify as official.
I'd test this on my cart, but my cart has been packed away and not easy to get at. Due to its rarity, this was done on purpose. If I dig it out, I am happy to poke around.
I do know that a NES booted from an absolute cold state does have a difference over it being run for a while, as noted from watching Feasel live stream FF1 attempts to get TAS monster charts.
Mr. Kelly R. Flewin
Mr. Kelly R. Flewin
Just another random gamer
----
<OmnipotentEntity> How do you people get bored in the span of 10 seconds? Worst ADD ever.
To quote your own source, verbatim, "Please note that you should NOT rely on the state of any registers after Power-UP and especially not the stack register and RAM ($0000-$07FF)."
Why? It is how this hardware works.
The less vague answer is actually on the same page: "The memory values are probably slightly different for each individual NES console." Also, considering there were different revisions of the console, it's always wise not to rely on something that isn't officially supported by the console.
But at the same time, you should never rely on the opposite (that all consoles behave as a hardware random number generator). It is likely that some patterns/sequences of values are even impossible to ever see in NES RAM at poweron.
True wrote:
Do you want to learn?
If one were to accept the rule change, then yes, the technical ground behind the change must be learned in full.
Though I don't like where this change would lead TASing in general. This is not TASing anymore, because heavy tools would be used to achieve smaller goals, and that's just not cool.
True wrote:
For a practical example, try replaying the fighter FF TAS on NES, and notice the first battle is almost always different.
I see, the game reads a few addresses before writing to them.
Anyway, your console behaving differently from the one at nesdev doesn't make an excuse for TASers to edit the initial state of games any way they wish and still deny to be called cheaters.
DrJones wrote:
However, this run is interesting if only because it tries to showcase a bug that cannot be emulated, even if it achieves this by questionable ways.
I wouldn't call this a showcase, since the movie doesn't reproduce the bug itself, it just starts from a state similar to the state achieved by the bug. Here adelikat used special initialization tags in his movie, but you can also use the good old "savestate" tag. For example, this FCEUX movie enters level 5 exactly the same way - by changing the initial state of the mapper registers, and leaving everything else with default values:
http://tasvideos.org/userfiles/info/10117227735638386
See, what's the difference between movies starting from a savestate and movies starting from a craftly customized poweron?
