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.
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.
I just want to know why we are allowed to change the firmware settings for NDS movies to get a better RNG without all this debate, yet changing the initial state is wrong.
I mean, the initial firmware settings for DeSmume is :
firmNickname yopyop
firmMessage DeSmuME makes you happy!
firmFavColour 10
firmBirthMonth 7
firmBirthDay 15
firmLanguage 1
rtcStartNew 2009-JAN-01 00:00:00:000
Since my NDS most likely has a different setting than this, does that mean I'm cheating?
Btw, still haven't got an exact reply regarding whether changing firmware counts as an arbitrary state other than it's determinism.
I just want to know why we are allowed to change the firmware settings for NDS movies to get a better RNG without all this debate, yet changing the initial state is wrong.
Firmware settings can be changed by the owner beforehand, and they are restored reliably when starting a movie. IIRC, manipulating these settings is even used by regular players (Pokemon/etc).
RAM values/mapper registers/other hardware quirks, on the other hand, are not as well examined, so you shouldn't be very picky, unless you have a proof that your chosen setup actually exists in hardware, not just in theory. And even then it would be more hacking than TASing.
I mean, I personally like hacking and reverse-engineering, but I know when I'm crossing the line.
jlun2 wrote:
Since my NDS most likely has a different setting than this, does that mean I'm cheating?
If NDS cannot possibly have these settings (e.g. because of some hardware limitations), then yes, you were cheating.
Since my NDS most likely has a different setting than this, does that mean I'm cheating?
If NDS cannot possibly have these settings (e.g. because of some hardware limitations), then yes, you were cheating.
er....now you're bringing up hardware limitations? I think Up/Down and normally other impossible input combinations were already pointed out in the SMW thread many times, so I'll instead bring up this quote:
RachelB wrote:
Huh? It goes past the normal circle range just fine. I know there's at least one game that even lets you move significantly faster than is normally possible because of this (like that kayak game swordless tased, for example).
er....now you're bringing up hardware limitations? I think Up/Down and normally other impossible input combinations were already pointed out in the SMW thread many times
Stuff that is normally impossible, but technically possible = field of TASing.
Stuff that is not even theoretically possible without modifying the game/console/etc = field of modding/hacking/etc.
Me and adelikat argued about this at great length. I eventually had to bless it.
Maybe some ram start-up states are possible, and some are not.
But a start-up state like what adelikat uses is possible, and it is proven by videos of cheetahmen II booting up to the target level after multiple power cycles (I tried to prove it was possible just by making the mapper malfunction through repeated zaps, and failed)
The FF 00 etc. initialization state we suggest emulators use is proven as more or less possible, due to multiple games depending on it.
If anyone else can prove that another ram start-up state is possible, then I guess they could use it. I don't think I would bless anyone choosing a start-up state without some documentation that it's possible.. on some hardware (if someone's going to make a policy, they should probably specify which nes/famicom models count as real, vs clones).
"Well, it's technically possible for the RAM to start in any configuration, even DEADBEEFDEADBEEF" doesn't work for me without proof. Here, we have proof.
You could even get something like a NESbot to play this movie, if you let it control the power cycling too. Eventually it would work, just like in the videos. If you ask me, NESbotability should be an ultimate decider in favor of legality.
I wish someone would try to reproduce this movie's trick by glitching the game into the right memory state and then issuing a reset. But adelikat wants to open a discussion, because we're the scientists of this stuff and who better than us?
But a start-up state like what adelikat uses is possible, and it is proven by videos of cheetahmen II booting up to the target level after multiple power cycles
Check these videos again, they are using Reset button instead of switching power off and on. Adelikat's movie doesn't use resets, so youtube videos don't validate the submission.
zeromus wrote:
If you ask me, NESbotability should be an ultimate decider in favor of legality.
Of course, naturally.
zeromus wrote:
You could even get something like a NESbot to play this movie, if you let it control the power cycling too. Eventually it would work, just like in the videos.
If NESBot were able to control the reset button then it could probably reproduce this bug... by playing a movie that uses subframe resets! (then again, maybe there's something else necessary)
As for this submission, NESBot would need to first recreate the bug on its own, and only then start replaying the movie input.
Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
AnS wrote:
As for this submission, NESBot would need to first recreate the bug on its own, and
only then start replaying the movie input.
Not true. The point is that you would have to attempt to run the bot many times before it finally worked.
And that's the fundamental concept that is going on here. I'm suggesting that a TAS need not work on all possible start up states to be legit, as long as it works on at least one possible state.
Not true. The point is that you would have to attempt to run the bot many times before it finally worked.
Doesn't NESBot require starting from console power on? At least the movie does.
Youtube videos make it look like you have to first let the game run for some (small) time and then reset at a very specific moment - perhaps exactly while the game is writing data into mapper port.
So, simply switching NESBot+console on at random occasions won't do the trick.
Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
What I'm suggesting is that you can do it from the power button alone. I wish I could prove it myself, if it were any other game, I'd buy a copy and record the phenomena
adelikat insists he had a video that was using the power button. I never saw it. I'm taking his word on it, but I'm very cranky about it. I still want to see it done by the power button. If it's possible via reset, I would prefer that we did it by reset. But if it's possible that it can be done by the power button, then I say we're forced to allow emulating it, even if reset is a better way.
Adelikat's movie uses the initial mapper register state only. The initial register state could be any nonsense on a crappy PCB. In fact, we did prove that it took zapping the mapper by proving that no initial memory state is used in the boot-up process. That's the opposite of what I said earlier. I'm sorry, I was confused in my last post. I'm not sure why we were talking about memory suddenly.
AnS wrote:
. Initializing these registers is the same as initializing CPU registers, which in turn is the same as initializing RAM.
Ah, here's why. Yeah, it's the same. But initializing RAM is a bigger can of worms. I'm glad we didnt do it, although technically, I suspect eventually we'll be forced to.
adelikat wrote:
I'm suggesting that a TAS need not work on all possible start up states to be legit, as long as it works on at least one possible state.
Define the TAS as a NESbot script, which includes the capability to power-cycle and check the results via a camera. Then, the TAS can work on "all possible startup states" by virtue of being able to align itself to its desired startup state.
I've seen the video too. The bug just cannot be reproduced by an emulator because unlike real hardware, emulators typically start with an empty memory.
That's why he had to hack the emulator so that it has data already written in it, which triggers the bug on "Cheetahmen II"'s poorly written code. This is unorthodox and a nightmare to judge, but also the only way to trigger this specific bug.
I asked if the bug was fixed in the kickstarter produced version (most likely not), because unlike the original version, this one is beatable.
You guys do what you gotta do but please keep in mind the image that making a run without just controller input conveys.
e: To clarify, I'd prefer if the emulator attempts to emulate a cold boot, even if it's imperfect or arbitrary, than to emulate what might happen if you power cycle at the right time. In fact, can't a power cycle be recorded? Should the power cycle be part of the setup?
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
As it stands, I'm not willing to have this video accepted, unless there's conclusive proof that this game can be powered on in an NES with this state used 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.
Not true. The point is that you would have to attempt to run the bot many times before it finally worked.
Doesn't NESBot require starting from console power on? At least the movie does.
Youtube videos make it look like you have to first let the game run for some (small) time and then reset at a very specific moment - perhaps exactly while the game is writing data into mapper port.
So, simply switching NESBot+console on at random occasions won't do the trick.
My bot allows starting from reset - it doesn't care about cold power or reset. But it doesn't itself control the reset line (though with a 1p TAS, I suppose I could include this support in the firmware using the 2p port - automatic resetting ;d)
I could also support turning the power on and off pretty easily.
Some games do act differently from reset and hard power (example: FF1)
If I had this game (ha) I could test this.
As it stands, I'm not willing to have this video accepted, unless there's conclusive proof that this game can be powered on in an NES with this state used here.
If instead of the criteria of "this game," would it instead be sufficient to simply prove that the PGR can take a value of 11 at the same time as a value of 1 for the mode from power on?
If so, crafting a ROM image that simply displays the value of the two memory locations at startup and flashing it to an NES cart would potentially more accessible than finding a copy of this specific and very rare game.
Build a man a fire, warm him for a day,
Set a man on fire, warm him for the rest of his life.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
OmnipotentEntity wrote:
Nach wrote:
As it stands, I'm not willing to have this video accepted, unless there's conclusive proof that this game can be powered on in an NES with this state used here.
If instead of the criteria of "this game," would it instead be sufficient to simply prove that the PGR can take a value of 11 at the same time as a value of 1 for the mode from power on?
If so, crafting a ROM image that simply displays the value of the two memory locations at startup and flashing it to an NES cart would potentially more accessible than finding a copy of this specific and very rare game.
In order to conclusively prove that this game can be powered on like this, you certainly don't need to use this game to do it. Any cart which is known to electronically exhibit the same semantics, and can be done with it would be fine too. Replacing the ROM image with something which displays register information on the screen is good also. But what needs to be proven remains the same, that from power on, the electronic state this run is presetting is in fact a valid scenario that can occur at power on.
Personally, I'd also be willing to accept running the ROM image for this game on any official Nintendo board that is able to run it without modification of it or the ROM image. But I don't know how others would feel about "swapping to another compatible board", and if when doing so, this state would even be possible. In any case, on this last point, many games on various consoles have different batches created with different boards which are compatible for the game. Therefore I'm willing to accept any board (which is official) known to be compatible, whether we know the game was indeed shipped at some point on that board, or not.
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.
Please correct me if I'm wrong, but I thought this game was never released commercially and the existing cartridges were found after the lifespan of the NES.
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.
Finally the submission arrived =)
Let me summarize some things we already know/discussed:
About the NES Cheetahmen II cart:
- Because of the mapper, you can abuse the same thing adelikat did with simply pressing the power on button, references: FAQ (End of V section) and Youtube video (no initial footage). It worths mentions that changing the ROM is unnecessary.
- (from BootlegGames wiki:) "Due to how messed up the game is, each copy works differently. This being probably because of how each copy is made differently with the soldering, etc. After all, it most likely isn't made with a machine, instead most likely by hand."
About the NES:
- RAM initialization is different than the original NES and the emulators we have
- Probably the PPU/CPU cycle difference also could change this behaviour
- As far as I know, the different revisions of NES' also could have different effect
So there's a lot of things that would be required to verifiy this phenomen. It's already known that you can go to level 5 with resetting the game. If the two sources I added are "reliable", it would mean you can do it with only power on.
Since I have no idea how mappers works nor the differences between each NES, I just approve the aforementioned idea of making a CART (no powerpak) to dump out memory (checksum / only part of it) on various NES and emulators to see the difference of RAM initialization. Ah, and check what values the mapper really loads in / changes / uses.
Once we know the RAM initialization of the real NES (systems) and what values the game uses (that manipulatable by powering on / reset), I (will) totally see this TAS legit. Until then, it's just a possibility surrounded with mist.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
MESHUGGAH wrote:
Once we know the RAM initialization of the real NES (systems) and what values the game uses (that manipulatable by powering on / reset), I (will) totally see this TAS legit. Until then, it's just a possibility surrounded with mist.
Most of the mist here is misunderstanding.
There is no exploitation of RAM initialization, thus the possible start up states of a NES is irrelevant. This TAS exploits ram REGISTER initialization. Registers are on the cart itself, not the NES. The cart itself in this case is a custom one made by the Action 52 company. The only 2 games that use this are Action 52 and Cheetahmen II.
There are 2 registers exploited in this tas. One is a 5 bit PRG bank register, it has 32 possible values, only 16 of which are relevant to the Cheetahmen II cart. Another is a 1 bit PRG mode value.
Board documentation
This document I keep linking isn't gibberish, it lays out exactly the issues people seem to think are unconfirmed.
Here's a significant one: "Apparently the games expect $00 to be written to $8000 on powerup/reset."
This is absolutely true about the game, unfortunately 00 will not be written to $8000 reliably. As stated by Zeromus, it is known that registers can start up in goofy values. It was known back then too. That's why good boards/games don't rely on a particular value, and actually write to the register first.
So Nach suggests maybe values can be random but how do we know THIS particular value can occur? Because it is the only combination that yields a playable game starting at level 5. And we have video evidence of this phenomena occuring on a real NES + Cart, exactly as demonstrated in this TAS. I'm not sure why this evidence isn't enough.
The demands beyond this evidence (which I think is more than adequate), I don't know how to acquire them, any suggestions? Do I need to pony up $1000 for a cart and video it myself?
What about the "each copy works differently" (Post #357537)?
"As stated by Zeromus, it is known that registers can start up in goofy values." -> All values are possible? Any way to check that? Yes, I read "Because it is the only combination that yields a playable game starting at level 5." but that doesn't proves it would work on all copies (if they are really different).
And how do you know that only these addresses are required to pull this off? Is it possible to rebuild a cart using this ROM and mapper while somehow (still have 0 experience on cartridges/mappers) force the same values you used everytime it powers up to bring the same state this TAS does?
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Emulator Coder, Site Developer, Site Owner, Expert player
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
MESHUGGAH wrote:
but that doesn't proves it would work on all copies (if they are really different).
I don't see why it would need to work on all copies. But given my understanding of this board, I don't see how variations in the cart could prevent this from happening. And the fact that the few people who have one have all seen/reproduced this glitch tends to suggest this fact too. I think the burden of proof is on you to prove that somehow this glitch can be prevented by a ...faulty?...board. But if you did prove that, what did you prove? That it works on most carts? some? Is it possible that some glitches on TASVideos don't work on a particular cart? Would this invalidate them?
And how do you know that only these addresses are required to pull this off?
It isn't a ROM value or a RAM value it is a register on the cart, there is a difference. And this TAS proves these values are the only ones needed to pull it off. These registers control which block of program data to run. You simply need to get it to read from the wrong block to start with, as I described in my submission. Nothing else is needed, nor is it logical to think that it would.
Is it possible to rebuild a cart using this ROM and mapper while somehow (still have 0 experience on cartridges/mappers) force the same values you used everytime it powers up to bring the same state this TAS does?
I would say this isn't relevant to the legitimacy of this TAS. However, I would say no, it is no more possible to force the values to what I set than it is to force them to 0. If you want to guarantee a certain value, you can 1) Design a board such that these values will be inevitably cleared (from my understanding of mappers, good mappers do this, but I could be wrong), or 2) program the game to write to these registers BEFORE reading them. A common sense thing most every decent game would do.
If the game makers had put this in a standard MMC1 or MMC3 board this glitch probably couldn't occur. And even then, all they had to do was do a register write of 0 at start up rather than assuming it would be 0. Their failure to do all these things is why this game has this glitch.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
adelikat wrote:
Board documentation
This document I keep linking isn't gibberish, it lays out exactly the issues people seem to think are unconfirmed.
Here's a significant one: "Apparently the games expect $00 to be written to $8000 on powerup/reset."
This is absolutely true about the game, unfortunately 00 will not be written to $8000 reliably. As stated by Zeromus, it is known that registers can start up in goofy values.
Is it known that registers can start up with the "goofy values" that can be exploited as you did here? The only evidence I saw is that it can be reset to "goofy values" that exhibit what you're exploiting here.
adelikat wrote:
So Nach suggests maybe values can be random but how do we know THIS particular value can occur? Because it is the only combination that yields a playable game starting at level 5. And we have video evidence of this phenomena occuring on a real NES + Cart, exactly as demonstrated in this TAS. I'm not sure why this evidence isn't enough.
You mentioned this already a page back, I accept it. That still doesn't tell us if the state you're using is possible on power on or not.
adelikat wrote:
which I think is more than adequate
Till you can prove power on, I find it far from adequate.
adelikat wrote:
I don't know how to acquire them, any suggestions? Do I need to pony up $1000 for a cart and video it myself?
I gave some suggestions prior. I don't care if you buy this exact cart, or hack up the Action 52 cart which is known to use the same board, or build your own board with parts from radio shack which our electronic engineers can feel confident would be a proper reproduction of the board in question.
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
(3574)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Till you can prove power on, I find it far from adequate.
Messuggah posted this
he says he is fiddling with the power button. I'm sure you will come back with the fact that you can't SEE him do that, maybe he is really using reset and lying! But the fact is, both are possible because it is the same problem in both cases. The game when starting up assumes the prg register to be 0.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
adelikat wrote:
Till you can prove power on, I find it far from adequate.
Messuggah posted this
he says he is fiddling with the power button. I'm sure you will come back with the fact that you can't SEE him do that, maybe he is really using reset and lying!
I wouldn't say he's lying per say, I'd say it's possible he's not being precise with his wording. We don't know if he really means on and off, or if he means he's resetting, which in his mind is equivalent to on and off. He also says: "This was recorded from a hacked rom file provided by CommieCatGirl" which is disturbing. What is hacked about it? If he's using his own custom ROM image, what board is he actually playing it on? This video and the comments with it does not contain anything which I'd consider meeting its burden of proof that the run you crafted can actually work.
adelikat wrote:
But the fact is, both are possible because it is the same problem in both cases. The game when starting up assumes the prg register to be 0.
Be that as it may, it doesn't tell us what states are possible at start up, and at reset, and if they're the same or not.
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.
Is the original Cheetahmen II preferable for publication over the fixed romhack? The 4-level run of the original was obsoleted by a run on the romhack since the former didn't complete the game fully. This submission plays the last two levels, which would make it complete the game fully. Howewer, the last level can't be properly beaten because of the bug with the last boss that's fixed in the romhack, so the romhack still allows for a slightly more full completition.
