Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
feos wrote:
I mean it starts from what values are on pure power on.
I think there is a misconception here. A pattern of WRAM that consists of 0000FFFF is not what values are on in a pure power-on. In fact, this is probably an extraordinarily unlikely event, and technically hasn't been proven to be possible. There is no pure power-on, and no consistency to which RAM starts.
This isn't a new insight either. Most games are unaffected by this randomness because the programmers make sure to clear them. Using unitialized RAM in assembly is a big no no.
Blank as in not touched.
In that case, it is blank, because it wasn't touched, it was simply one of the many possible states the cart could be in, on power-on.
You just can NOT start it from the state similar to other movies :) Because it screws up the values by itself.
(I am interpreting "all movies" as other NES TASes, but you might mean other Cheetahmen II TASes) Registers are on the cart itself, so no you can't start other movies this way since those carts do not have them. However, the NES WRAM space is something they all share. A vast majority of games would be unaffected by starting in various RAM states since most carts work with any configuration, and most games initialize addresses before using them.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
feos wrote:
is to figure out how exactly power on affects the needed register state, and when it affects it.
This IS known. Power doesn't "affect" it. On power-on the state of registers is unknown, therefore it could be anything.
Like, does it depend on the stage you switch the power at? How much time in is needed? How many times one needs to do it to get the needed state the soonest?
No to all of these. It is due to the fact that the register states are truly random. These things may seem to affect it, or maybe they do help lean it one way or the other, but the point is, it is random, so in theory it could start in this state on a cold power-on, on the first try, instantly. Did I mention random?
But it can not be treated as movies starting from "blank" state
There is a bit of a misconception here. What is a blank state? I guess you mean where all relevant registers are 0, which is actually an unlikely event.
Also, no NES TAS starts from a "blank" state. It starts with WRAM set at 0000FFFF. Why is this "blank"?
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
In this specific case, this run uses a rather likely event. One likely enough that should someone RT speedrun this (oh god why), they could easily incorporate this glitch and start from level 5.
The video I linked shows it happening less than a minute of trying. And that was his second attempt because he forgot to put the power button in the video the first time. The first time it happened in only 4 tries.
Starting at level 1 I suspect is only more likely because there are more register states that lead to level 1, whereas level 5 happens to only have 1 combination.
However, I don't support the notion of "equally likely" as something to base site rules upon.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
We make no effort for any given trunk revision to be stable. If you want the latest svn and want it to be stable, use the 1.5x branch instead of trunk.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
Nach wrote:
Your evidence is good. Only question left is the state, you keep talking about the state of the PRG register. Are there other registers? If you're using a state, the combined state of all registers needs to be valid. If you tell me there are no other registers, or the game initializes them fine.
I've linked this too may times, your question clearly shows you haven't even bothered to click it
but I will appease you and put it directly in this post! To save you 1 click:
1 bit prg mode(needs to be 1 in this movie)
5 bit prg bank (needs to be 11 in this movie)
5 bit chr bank (can be anything and achieve these results, irrelevant, as char usually is, worst case you get a garbled but playable game
1 bit mirror register (irrelevant here, either value has no effect on start up behavior)
1 bit bank size - only action 52 uses this
2 high prg bits - only action 52 uses these
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
An owner of the game was kind enough to make a more thorough video demonstrating this glitch, here is video proof. This video shows it can (easily) be recreated by ONLY pushing the power button.
Here's a brief summary of the proof I'm offering:
1) As shown, this glitch can occur from simply powering-on the game. The only possible explanation of that behavior is some sort of variable being in an unknown state and used
1) messing with the initial RAM pattern (0000FFFF) has NO effect on this game. I tried, via scripting enough random combinations using this technique (all 0's, all 1's etc, then pure random patterns). I left a script running for some days and never once did the game do anything but start normally. This eliminates the NES's ram as the culplrit.
2) Debugging shows that the game runs a for loop to clear out the NES WRAM space, so it is expected that random ram initializations would not affect the game
3) The only other variables in play would be on the cart itself (these are mapper registers). This game have prg registers to control which part of the program to execute from. Messing with these values give you consistent results with the videos showing this glitch, including starting from level 5
4) There are 32 possible PRG register combinations, only one of which starts you at level 5 and in a playable state.
5) This movie uses that one combination and produces results IDENTICAL to video evidence
6) Videos evidence shows that this can be done from reset OR power, and that this is consistent with the theory that it is a random register issue
7) "How do we know this EXACT register state is possible?" It is KNOWN among EE people that registers can be in a random state. In this case is 6 bits, nobody has said anything other than it is likely and reasonable to assume all are possible states. Furthermore, the results produced are identical to video evidence, AND there is only 1 combination that yields this evidence. And if there wasn't more than one, who cares? If I put in 13 instead of 11 and they both produce this, the end video is identical.
I personally think that I've given more than enough evidence to suggest that this is the explanation of how this glitch is occurring and that the emulator is faithfully emulating this behavior. Can we move on from me defending the TAS itself? The implications of accepting this movie's premise (exploiting the initial hardware state) is a good debate and worth having, and I hope we will focus on that now, going forward. (Note: this post intentionally avoids this subject, but I do have a lot to say on the matter)
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
Upon further debugging, the latest BizHawk does not have a bug, if "PAL 1" is added to the movie, it reports 5:50 as it should. I recorded a fresh new movie with the E version and "PAL 1" was added to the my movie.
This movie does not have this line, and was created with 1.4.1 which is out of date. I think this bug probably existed back then but was fixed since this release.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
The problem is that you are running the PAL version (which is designed to run at 50 fps), at NTSC speeds (60 fps). You did not break any records, your movie at pal timing is about 5:50.
If you are attempting to make a series TAS, don't use the E version! Refer to the
Movie Rules for more info.
EDIT: And it turns out there is a bug in BizHawk, it reports PAL game times based on 60fps instead of 50. *Adds to the TODO list*
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
Your movie is 17507 frames, which at 60.1 frames per second correctly calculates to about 4:51 just like BizHawk reports. It is not incorrect.
Your movie, however, does not match the sha1 of the correct SMB ROM and doesn't play back at all. I'm not sure which version you are using.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
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.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
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.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
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?
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
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
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
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.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
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)
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
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.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
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.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
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.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3602)
Joined: 11/3/2004
Posts: 4739
Location: Tennessee
BizHawk 1.5.2 Released!
The big change in this release is completely redone Ram Search, Ram Watch, and Cheats tools. With the demands of N64 TASing, I had to add more support for things like float and fixed point, and tighten up ram usage and performance.
Another fun feature is the ability to load games on the ti-83 core.
As usual, I recommend reading the
full release notes.
Windows binary
