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.

Summary

  • Requires BizHawk (or later)
  • Heavy glitch abuse (the whole game is a glitch though
  • Skips most of the game (Good, because the game is bad)
  • First submission to exploit the random initial state of hardware

feos: Delaying since adelikat is going to beat teh boss!

adelikat: Replaced submission file with one that does in fact "beat teh boss!"
feos: Accepting to Vault and publishing...


1 2
5 6 7 8
Former player
Joined: 8/15/2004
Posts: 422
Location: Minnesota
Is there an encode for this run?
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
adelikat wrote:
My admin/judge ruling is that we should discuss and vote as a community as to whether unitialized ram/register exploitation should be allowed. This should probably be a separate thread and maybe a poll.
Here. Please vote and discuss!
It's hard to look this good. My TAS projects
Player (26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
feos wrote:
I have no problems with calling "glitched" runs "any%" and the current "any%" ones that have the faster glitched versions something else, as long as the low-glitch versions are preserved if their entertainment value deserves separate publication.
I believe this is key, and this is also why the vault only allows Any% and 100% runs: "low-glitch versions are preserved for their entertainment value". They are: that's what moon tier is for. If a run shows off more of the game by not clipping through walls, not going out of bounds, and avoiding warp zones, then the run is judged on entertainment and eligible for moon tier if people like it. But vault tier and any% are about reaching the end of the game using any and all tricks in the book, and regardless of how garbled ridiculous this looks in the video. And because of this, runs that exploit some glitch obsolete runs that don't use that glitch; as far as I've seen this is consistently applied. That doesn't apply to runs who corrupt memory to execute an arbitrary program, but those are pretty rare. It does apply to any other glitch, because we can't objectively define a difference between a "high glitch" vs a "low glitch" run.
Personman wrote:
There are plenty of Vault examples too; that rpg that wins on the first frame comes to mind.
King's Bounty?
Site Admin, Skilled player (1254)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
Personman wrote:
feos wrote:
It does skip more than half of the game at once. It in no way near the any% concept either. The game itself is just fucked up, so you don't even need to corrupt memory to break it to death and abuse.
This is the most ridiculous thing I've ever heard. By this logic, the mario64 0-star run isn't an any% run. There are plenty of Vault examples too; that rpg that wins on the first frame comes to mind. The entire point of any% is to complete the game as fast as possible. If we can skip 99% of the game, we absolutely should. Trying to separate it from memory corruption is one thing (that I personally don't agree with, and which certainly doesn't apply here), but trying to define a percentage of the intended game that must be completed is just crazy.
I think you missed the part where I said that no one bothers. Calling something ridiculous doesn't help, you know. Spawning a serious discussion about what you are interested in, does help though.
adelikat wrote:
feos wrote:
But currently it is just not the case. So I'm speaking in consistency with the current categorization.
That's fine, except that you must understand that the vault wording isn't based on that. Whether that is an error is up for debate, but the meaning of "any%" means fastest completion time at all costs.
I must not need to guess what a word means to someone. I look at the page, I read any%, I look at the published movies, any% is skipped from the branch name, glitched isn't. any% != glitched by what I see on the site.
Radiant wrote:
feos wrote:
I have no problems with calling "glitched" runs "any%" and the current "any%" ones that have the faster glitched versions something else, as long as the low-glitch versions are preserved if their entertainment value deserves separate publication.
I believe this is key, and this is also why the vault only allows Any% and 100% runs: "low-glitch versions are preserved for their entertainment value". They are: that's what moon tier is for. If a run shows off more of the game by not clipping through walls, not going out of bounds, and avoiding warp zones, then the run is judged on entertainment and eligible for moon tier if people like it. But vault tier and any% are about reaching the end of the game using any and all tricks in the book, and regardless of how garbled ridiculous this looks in the video. And because of this, runs that exploit some glitch obsolete runs that don't use that glitch; as far as I've seen this is consistently applied. That doesn't apply to runs who corrupt memory to execute an arbitrary program, but those are pretty rare. It does apply to any other glitch, because we can't objectively define a difference between a "high glitch" vs a "low glitch" run.
Great point. If something is once again adjusted at the Vault page, this run is even perfectly vaultable to obsolete the current one. Switching to the savestate discussion now.
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.
Active player (309)
Joined: 8/21/2012
Posts: 429
Location: France
adelikat wrote:
3) This and the currently published movie (that uses the fixed) version are vault compatible I think. This movie serves as the fastest possible completion (any%), while the other movie shows all levels (100%)
I'd add another (additional?) factor to differentiate the two runs: this one uses the original game rom, the other uses a modified rom (created only to make the game playable, but still modified). Hum, I don't remember if it has been mentioned, but is it possible to skip the four first levels on the modified version too, with the same technique? Anyway, if it is possible, I don't think it's worth it. I could see the two runs being "fixed version, 100%" and "original version, specific power-on state", or something like that.
RachelB
She/Her
Player (129)
Joined: 12/3/2011
Posts: 1579
And we have some precedence for this. DS movies specify RTC. In real world terms, that means that a DS must be powered up at EXACT a particular point in time for the TAS to sync. To DSbot my NSMB tas for example, you would also need a time machine (or set your internal clock to the correct time, but that's a less fun example). These TASes are considered valid, because this is a valid state for a DS to be in on power-on. Yet, this is information that could also be attained at a point in the timeline beyond 0, therefore a movie could start from a savestate and achieve the same results.
Same thing with gamecube and wii.
Post subject: Encode of Cheetahmen II, please!
Moderator, Senior Ambassador, Experienced player (907)
Joined: 9/14/2008
Posts: 1014
Ouzo wrote:
Is there an encode for this run?
I've been waiting for an encode as well. I do not own a copy of Cheetahmen II which is probably something I'm not alone in. :) A.C. ******
I was laid off in May 2023 and became too ill to work this year and could use support via Patreon or onetime donations as work on TASBot Re: and TASBot HD is stalled. I'm dwangoAC, TASVideos Senior Ambassador and BDFL of the TASBot community; when healthy, I post TAS content on YouTube.com/dwangoAC based on livestreams from Twitch.tv/dwangoAC.
Editor, Experienced player (570)
Joined: 11/8/2010
Posts: 4036
I don't know about anyone else, but I can't open this movie file in BizHawk 1.5.2, even after copying the input over to a new movie file along with the prg setting lines. I always get this error: I can post the Details if someone requests them, but I won't until then because it's pretty long.
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
Yeah, someone pointed that out, this particular movie breaks the play movie dialog of bizhawk, just drag and drop the file onto the emulator and it will work just fine.
It's hard to look this good. My TAS projects
Editor, Experienced player (570)
Joined: 11/8/2010
Posts: 4036
I didn't know that was even possible! That's cool. Thanks! Here's an encode. You can add it to the submission text if you want, adelikat. Link to video
Spikestuff
They/Them
Editor, Publisher, Expert player (2642)
Joined: 10/12/2011
Posts: 6438
Location: The land down under.
adelikat broke his own creation.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
Joined: 1/17/2008
Posts: 133
I am confused as to where the 6 bits of register reside, that is read from before initialization. I am led to believe from what I have read here that it is on the cart itself. Is it part of the game cartridge itself or are these registers in the NES hardware? If it's part of the cartridge, how many other games depend on such aspects of the cart vs the console? I'm not here to contribute to the debate for/against accepting this, just thinking about the difficult of broad policies here that would be best to have. I believe in a consistent state of the console hardware to be applied as widely as possible. And I see issues like the RAM as being part of the console that should be level for all. (I know this game/submission is nothing to do about the RAM) Regardless of this current situation, it should be rules that we are assuming console ram initialized as what current emulators initialize it as. It should be mentioned any other values we are also assuming. Messing with things that would be on the cartridge and not in the console is different to me and not necesarily something to instantly reject on principle. As Nach believes, and I am with him fully on this, it's all a means to the end of reasonably emulate the software in a deterministic way. What we have here is an emulation nightmare caused by software flawed in a major way. Maybe these will always be unique corner cases. But I thought we had many games where it was accepted that we cuold not emulate elements of randomness intentionally chosen by use of registers or ram or other data of a unknown initial state. I thought the status quo was to just go with the emulator defaults, accepting it as not the best possible hardware luck. Example being the pokemon games that, IIRC, use screen blank timing or values, or something else related to the physical LCD on the hardware, to initialize random seeds. Is this really all that new? What's been the running policy? Should we consider the game software to be just the software code on the cart, or everything that the console would be black-boxed away from on the opposite side of the cartridge contact pins (as far as the console is concerned with it)? If we allow ourselves to choose initial states of cartridge hardware, is that not a can of worms? Do we have to assume and follow some established defaults, until we can definitively prove a quirk of the cartridge hardware, and how it works, and its full ramifications? Then they're fair game to use? I don't like the direction that would take. At the same time I can't disagree with adelikat's argument for allowing this particular case. Extraordinary circumstances for an extraordinary cart.
Joined: 1/17/2008
Posts: 133
I found these posts, nearly consecutively, in the X-man gruefood thread. It made me think of this game, and I think they are relevant here, but were not explored to satisfaction. So keep in mind I am not quoting or responding to posts from this thread, but from another, and applying them here
mklip2001 wrote:
Also, there's another question worth considering: is this an official game? I don't remember if TASVideos also changed its policies concerning unlicensed games / hacks when it adopted the Tier system.
This game has more in common with a shitty hack or homebrew than a game. We might not be considering it for the site if not for notoriety. You could argue against having a run of this game for this reason.
Heisanevilgenius wrote:
Voting no. Actually the reason I'm voting no is because this run does not complete the game.
- The final boss is not killed and it could be argued this does not agree with the spirit of progressing to the point at which you can no longer continue. This was not adequately resolved for me. -Do we have other games that instantly load at the non-beginning level from launch? This is an issue for me too. And I do actually enjoy the novelty of this run and appreciate what it does. But again on this point, I cannot reconcile what is happening here with my understanding of what we accept.
Spikestuff
They/Them
Editor, Publisher, Expert player (2642)
Joined: 10/12/2011
Posts: 6438
Location: The land down under.
so who's judging this before it goes crazy on yes and nos (without explaining why they felt that way... I mean it was a clear accept (by a bit) and then all these nos started appearing out of nowhere without explanation on why)?
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
Player (26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Spikestuff wrote:
so who's judging this before it goes crazy on yes and nos (without explaining why they felt that way... I mean it was a clear accept (by a bit) and then all these nos started appearing out of nowhere without explanation on why)?
Remember that the votes aren't for "should we accept this run", but rather "did you find this run entertaining enough for Moon or Star tier".
Spikestuff
They/Them
Editor, Publisher, Expert player (2642)
Joined: 10/12/2011
Posts: 6438
Location: The land down under.
Radiant wrote:
Remember that the votes aren't for "should we accept this run", but rather "did you find this run entertaining enough for Moon or Star tier".
That's why Meh exists. Meh is the reason for good but better for vault. feos & Nach feos #2 (yes I looked at all posts I know what happens after that)
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
Noxxa
They/Them
Moderator, Expert player (4124)
Joined: 8/14/2009
Posts: 4090
Location: The Netherlands
Having seen the run now, I really don't like the way the run ends. There's no visual indication of any sort that you completed the game, and the way you die after 'finishing' the final boss just makes it look like the opposite. I don't think it's possible to make a speedrun of the game in this state. There just isn't a clearly definable win condition, as far as I can see. Even now it's not even obvious (outside of watching RAM values) that you are actually progressing 'as far as you can go' in the bossfight/game. So yeah. I vote against publication.
http://www.youtube.com/Noxxa <dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects. <Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits <adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
Radiant wrote:
Remember that the votes aren't for "should we accept this run", but rather "did you find this run entertaining enough for Moon or Star tier".
And once again we see why there should be an option for "this should not be published". I honestly cannot understand why there can't be such an option. Just add it already, sheesh. Stop being so stubborn.
Player (26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Warp wrote:
I honestly cannot understand why there can't be such an option. Just add it already, sheesh. Stop being so stubborn.
I think you should tell that to the site admins, not to me.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
I have. Repeatedly.
Player (26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Warp wrote:
I have. Repeatedly.
So does that mean you're being... stubborn? :P
Player (100)
Joined: 3/20/2008
Posts: 466
Location: Montreal, Quebec, Canada
Voting no because dying on the last boss looks ridiculous for a published run.
Spikestuff
They/Them
Editor, Publisher, Expert player (2642)
Joined: 10/12/2011
Posts: 6438
Location: The land down under.
Vykan12 wrote:
Voting no because dying on the last boss looks ridiculous for a published run.
That's quite silly of you to write because This and a few other TASes have death as final input. Also it might have been done for entertainment too... And now I must leave this thread because it's just bleeeeeeeeh..........
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
Active player (328)
Joined: 2/23/2005
Posts: 786
We should have a new goal choice: "Aims for highest controversy" It seems to be the goal of many of the new movies lately. I admit it's kind of entertaining to watch.
Noxxa
They/Them
Moderator, Expert player (4124)
Joined: 8/14/2009
Posts: 4090
Location: The Netherlands
Spikestuff wrote:
Vykan12 wrote:
Voting no because dying on the last boss looks ridiculous for a published run.
That's quite silly of you to write because This and a few other TASes have death as final input. Also it might have been done for entertainment too...
Uh, no? That run takes a bit of damage and then reaches the ending. I doubt there's any run on the site that stops just before reaching the ending. The closest I can think of is this rejected Spyro 3 run. (Though that one was due to emulation problems instead of game problems.)
http://www.youtube.com/Noxxa <dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects. <Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits <adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
1 2
5 6 7 8