1 2 3 4 5
Posted: 10/30/2013 5:27 PM
Post subject: Site policy regarding Alternative RAM stats on Power-up
Quote
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
TASer of 2010 NES TASer of 2010 DS TASer of 2010 Arcade TAS of 2010 NES TASer of 2008 NES TAS of 2008 Funny TAS of 2008 TASer of 2007 NES TASer of 2007 Funny TAS of 2007
My motivation behind my Cheetahmen II submission was to show bring up this issue and show off the potential it has for TASing, and the potential ramifications it has on the site. For those unaware of the situation, hardware RAM is in an undetermined state on power-on (meaning it is unknown as to whether it is 0 or 1). Most any game is programmed to not assume, and set the desired value before using it. However, some games fail to do this due to bad programming or a small oversight in a particular situation. This causes indeterminacy, which is experienced by anyone trying to get a TAS to sync using a bot. Another example of this discussion is regarding Blades of Steel. The opening movie is different due to the fact that the rng is seeded by unitialized RAM. Up to now, we have just used the "default" state that an emulator chooses to intialize RAM. The emulators we rerecord on have a defined default state, however some emulators should use to use a random value when initializing to simulate the indetermancy of hardware. This is at odds with syncability so we prefer emulators not do this, and would mod them if necessary to avoid it. However, there isn't necessarily a logical default state. For instance, some games break if the nes is all 0's. As such the FCE emulator a LONG time ago used the pattern 0000FFFF00000FFFF because it gave good compatibility (popular games that requrie a non 0 pattern work, and only a handful of very obscure pirated games are known to fail from it). By convention FCEU, FCEU-rr, and FCEUX still use the core from this emulator to this day so we have had the convention of it being the basis for TASing. NESHawk also adopted this pattern because it was easy to choose that vs trying to do some other scheme. However, these decisions are based on emulation considerations not TASing. With my cheetahmen II submission I show another alternative. We can have our cake and eat it too. We can have determinism by an emulator having a default state. We can exploit randomndess by having a movie FEED a particular (valid) state into the core to use as its power-on state. This allows us to do things like get a more favorable RNG state. An example of this is potentially Friday the 13th for NES. I've did some experiments and it looks like the RNG is using unitialized RAM. It may be possible to get a RNG state that could improve the current TAS. In more complex scenarios we may be able to do amazing things to a SNES game. We could have an entire program sitting in unitialized memory, and through memory corruption techniques maybe we could get the game to start executing at this point and completely take over the game (hypothetical, and unlikely, but certainly interesting). However, this is a potentially controversial decision. While I favor the idea (and vote yes on this poll), I think we should decide, as a community, what to do in terms of site policy.
It's hard to look this good. My TAS projects
Posted: 10/30/2013 5:37 PM
Quote
WST
She/Her
Active player (489)
Joined: 10/6/2011
Posts: 1697
Location: RU · ID · AM
adelikat wrote:
In more complex scenarios we may be able to do amazing things to a SNES game. We could have an entire program sitting in unitialized memory, and through memory corruption techniques maybe we could get the game to start executing at this point and completely take over the game (hypothetical, and unlikely, but certainly interesting).
My Little Pony in Sonic the Hedgehog? Hehe, kidding But I’m voting yes, since random initial state is possible on real hardware, and thinking of what benefits it could give in theory… However, I think that runs which abuse the initial state that differs from the emulator’s default, should not obsolete the «normal» ones when publishing.
S3&A [Amy amy%] improvement (with Evil_3D & kaan55) — currently in SPZ2 my TAS channel · If I ever come into your dream, I’ll be riding an eggship :)
Posted: 10/30/2013 5:40 PM
Quote
Radiant
Player (26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
To my mind, this is the same principle as games that act differently depending on the system clock. For instance, there are numerous games that make things harder for the player if played on Friday the 13th. Following our policy of TAS'ing games at the hardest difficulty rate, it would make sense to set the (emulated) system clock to Friday 13 for these games. So yes, this should be fair game for TAS'ing.
Indie game developer
Posted: 10/30/2013 5:48 PM
(Edited: 10/30/2013 5:51 PM)
Quote
feos
Site Admin, Skilled player (1251)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
Before I read the post: We should expand our TAS playground by all that is achievable in real life. It would require tricky emulation features (keeping the CD-drive open and whatnot), but as long as it happens, it is justified. If games fail to initialize something, it's their fault.
WST wrote:
However, I think that runs which abuse the initial state that differs from the emulator’s default, should not obsolete the «normal» ones when publishing.
They will have to, if the low-glitch versions are not entertaining.
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.
Posted: 10/30/2013 5:49 PM
Quote
ais523
Editor, Player (44)
Joined: 7/11/2010
Posts: 1029
I'm against it mostly because it greatly increases the bandwidth with which the player can communicate with the game, giving an unfair advantage. Many perfectly well-designed games are careful not to use memory before initializing it, so uninitialized memory normally doesn't matter. If, however, you gain control of the instruction pointer via a glitch, you can send it into uninitialized memory "early", before the program starts using it, and in many games it will still have its original contents if you do that. Now, normally a TAS would have to do complicated things in order to get a program into memory (first setting up a bootstrap, then using that bootstrap to enter a program); everything is done via controller inputs, and because a game typically won't have a bootstrap in memory naturally, you need to do complex in-game actions in order to set up the desired memory state before jumping there. If you can just insert the bootstrap (or even an entire program) via uninitialized memory, then there's no point in doing all that (which for me is the main entertainment of the run); you just jump off to unused memory and find that there's a complete program to do whatever you want there. In other words, this moves total control TASes from playing the game, to moving the instruction pointer; there's no longer a need to play the game in order to actually achieve what you want to do with the game. It also means that most likely, all goals within the game will have an identical input file; all TASes will just be "fastest known jump to uninitailized memory" + "program that does whatever you want". This isn't just restricted to badly-written or obscure games, either. Ilari informs me on IRC that both SMW and SMW2 would be shorter (and in my opinion less interesting) if uninitialized memory were allowed, much shorter in the case of SMW2. (The existing SMW2 run apparently creates lots of lag to be able to assemble the bootstrap without the game interfering; this wouldn't be necessary if the bootstrap just randomly happened to be in memory anyway.)
Posted: 10/30/2013 6:03 PM
Quote
feos
Site Admin, Skilled player (1251)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
Read the post. We can already start from presetting some mapper register to whatever value the devs did not care about and publishing it. But to start abusing uninitialized RAM officially, we will need to make some real hardware tests with test ROMs written to flash cards. So that the very first values that are read from RAM are displayed on the screen as a table, allowing to scroll through it all and document (dump somehow?) For several copies of each console we TAS we need to run these tests to collect scientifically reliable stats. Then we can change the "default" RAM pattern to something verified by real life. That is for movies that don't rely on dirty RAM. And then we would allow to set the values arbitrarily, with a special tag in pubs. So introducing some breaking and brand new concept only requires good statistical base and emulation support. EDIT: There is an omnipresent point of view that these tricks kill the spirit of tool-assisted speedrunning. Well, they don't kill anything as long as it is still here, public and available. But these features open a great room for that Demo tier thing. Will anyone consider its need when it's not playing the game, but fucking around with it? I can't pick an easier word when I hear about total control runs and uninitialized RAM potential.
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.
Posted: 10/30/2013 6:20 PM
Quote
got4n
Experienced player (588)
Joined: 2/5/2011
Posts: 1417
Location: France
TAS of 2017 First edition TAS of 2017 PSX TAS of 2017 Rookie of 2013
Voted YES =) .
Current: Rayman 3 maybe? idk xD Paused: N64 Rayman 2 (with Funnyhair) GBA SMA 4 : E Reader (With TehSeven) TASVideos is like a quicksand, you get in, but you cannot quit the sand
Posted: 10/30/2013 6:50 PM
Quote
Derakon
Joined: 7/2/2007
Posts: 3960
My general attitude towards this kind of thing is that if your approach could realistically be replicated on the console, then it's legit. So my suggestion is that we create some kind of threshold to decide how realistic a given starting RAM state is. If you require too much initial setup to happen entirely by chance, then your movie is a statistical impossibility and is incredibly unlikely to ever be replicated even by the most accurate TASBot. For example, we could say that if you need to have more than 32 bits have precise values, then your movie is too demanding. After all, assuming random bit states that's a 1 in 4 billion chance -- if it took you 1 second to attempt each run, you'd be running, on average, for 136 years before you'd get a version that synced. On the other hand, a run that only required 8 bits to be specific values would need, on average, 256 attempts, which isn't unreasonable. Of course, if you can achieve the RAM state you want in the game and then reset the console, then you have much better odds of having the specific memory state that you want.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Posted: 10/30/2013 6:51 PM
Quote
Denial140
Player (204)
Joined: 8/18/2013
Posts: 146
Location: location, location!
Arcade TAS of 2023
If they are valid RAM states, why shouldn't we, and why wouldn't we allow them? Voted yes.
Current TAS: [SNES] Jelly Boy [NES] Street Fighter 2010
Posted: 10/30/2013 6:54 PM
Quote
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
TASer of 2010 NES TASer of 2010 DS TASer of 2010 Arcade TAS of 2010 NES TASer of 2008 NES TAS of 2008 Funny TAS of 2008 TASer of 2007 NES TASer of 2007 Funny TAS of 2007
Derakon wrote:
My general attitude towards this kind of thing is that if your approach could realistically be replicated on the console, then it's legit.
This is a reasonable suggestion except for that fact that we generally deal in absolutes. When has "how possible" ever been a factor with TAS techniques? We have RNG abuse to the point that the heat death of the universe will happen before a reasonable chance of reproducing the TAS. I am resistant to the idea (not sold against completely) of having to deal with how likely something is. In fact the more unlikely the more fascinating it is to me.
It's hard to look this good. My TAS projects
Posted: 10/30/2013 7:02 PM
Quote
feos
Site Admin, Skilled player (1251)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
Derakon wrote:
For example, we could say that if you need to have more than 32 bits have precise values, then your movie is too demanding. After all, assuming random bit states that's a 1 in 4 billion chance -- if it took you 1 second to attempt each run, you'd be running, on average, for 136 years before you'd get a version that synced. On the other hand, a run that only required 8 bits to be specific values would need, on average, 256 attempts, which isn't unreasonable.
To introduce something into TASing, we don't need to prove that something is likely enough to happen. We only need to prove it is possible at all. That's where you will need test ROMs and quite some stats.
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.
Posted: 10/30/2013 7:03 PM
Quote
hegyak
Editor
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
I voted yes because controlling the console is something that gives the overall impression of God playing a game versus a highly skilled player. A beneficial RAM state is something that a normal player could in theory get (it's random after all) but having a consistent beneficial RAM state when you want it, is representative of the power of TAS. The only caveat I have is, the state MUST be valid for the console. Even if the odds of that state are 1 in Infinty-1 if it's valid, it's OK by me.
When TAS does Quake 1, SDA will declare war. The Prince doth arrive he doth please.
Posted: 10/30/2013 7:04 PM
Quote
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
TASer of 2010 NES TASer of 2010 DS TASer of 2010 Arcade TAS of 2010 NES TASer of 2008 NES TAS of 2008 Funny TAS of 2008 TASer of 2007 NES TASer of 2007 Funny TAS of 2007
feos wrote:
That's where you will need test ROMs and quite some stats.
Well, that essentially achieves the same results as Derakon is suggesting. Because it has to be likely enough that a human could verify it to be possible or else we will never be able to verify it being possible.
It's hard to look this good. My TAS projects
Posted: 10/30/2013 7:18 PM
Quote
Derakon
Joined: 7/2/2007
Posts: 3960
adelikat wrote:
This is a reasonable suggestion except for that fact that we generally deal in absolutes. When has "how possible" ever been a factor with TAS techniques? We have RNG abuse to the point that the heat death of the universe will happen before a reasonable chance of reproducing the TAS. I am resistant to the idea (not sold against completely) of having to deal with how likely something is. In fact the more unlikely the more fascinating it is to me.
I meant "reproducing" in the TASBot sense, not in the "human gameplay" sense. Absolutely TASing should be about doing superhuman things. However, I'm not convinced that picking and choosing the ideal initial console state is "playing by the rules", so to speak. The way I see it, TASing occurs within a closed "universe". The universe consists of the console and its input devices, the game, and presumably a display and speakers. The TASer enters into this closed universe after it has been created, and, with perfect knowledge of the state of the universe and perfect timing, manipulates the input devices (possibly including reset, power off, eject, etc.) to achieve their desired goals. Those are "the rules" from my perspective, and I grant that others may feel differently. It sounds to me like what is being proposed here is generating many different "universes" -- potentially googols or more of them depending on how picky you are -- until you get the one with the desired perfect initial conditions, and only then will you deign to enter the universe and start controlling things "normally". Don't get me wrong, if you make an entertaining movie then I'll be happy to watch it. I just can't shake the feeling that this kind of thing, except in very limited circumstances, amounts to cheating. If poking the console's memory with a magnetized needle is the only way to realistically be able to replicate the TAS on real hardware, then something has gone wrong somewhere. It's like using a Game Genie. ...in fact, yes, that's the problem here. Functionally you're using a Game Genie to adjust memory to exactly your specifications. The fact that no Game Genie is actually present doesn't change that that's the effect that's being accomplished.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Posted: 10/30/2013 7:24 PM
Quote
Radiant
Player (26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Derakon wrote:
...in fact, yes, that's the problem here. Functionally you're using a Game Genie to adjust memory to exactly your specifications. The fact that no Game Genie is actually present doesn't change that that's the effect that's being accomplished.
That depends entirely on what you're doing. If you can get the desired settings by adjusting the system clock (on systems that have one), or by turning the console off and on a dozen times, then you're clearly not using a game genie.
Indie game developer
Posted: 10/30/2013 7:31 PM
Quote
henke37
Editor
Joined: 3/10/2010
Posts: 899
Location: Sweden
This boils down to starting from a savestate and/or battery powered ram. Just with a tiny part of the state locked down to some arbitrary "start state" like the instruction pointer in the processor at a set place.
Posted: 10/30/2013 7:35 PM
Quote
WST
She/Her
Active player (489)
Joined: 10/6/2011
Posts: 1697
Location: RU · ID · AM
Derakon wrote:
The way I see it, TASing occurs within a closed "universe". The universe consists of the console and its input devices, the game, and presumably a display and speakers. The TASer enters into this closed universe after it has been created, and, with perfect knowledge of the state of the universe and perfect timing, manipulates the input devices (possibly including reset, power off, eject, etc.) to achieve their desired goals. Those are "the rules" from my perspective, and I grant that others may feel differently.
I totally agree with this, that’s why I mentioned that I wouldn’t like such runs to obsolete the «regular» ones. But curiousity about seeing what is possible if we allow choosing the initial hardware state, makes me voting «yes».
S3&A [Amy amy%] improvement (with Evil_3D & kaan55) — currently in SPZ2 my TAS channel · If I ever come into your dream, I’ll be riding an eggship :)
Posted: 10/30/2013 7:44 PM
Quote
feos
Site Admin, Skilled player (1251)
Joined: 4/17/2010
Posts: 11475
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
adelikat wrote:
feos wrote:
That's where you will need test ROMs and quite some stats.
Well, that essentially achieves the same results as Derakon is suggesting. Because it has to be likely enough that a human could verify it to be possible or else we will never be able to verify it being possible.
It's not the same. He wants a proof it is frequent enough. I want a documentation that will directly help improving emulators in the needed way, and tell people it is possible at all (as in, even 1 chance in 123456 million years is possible "at all"). So stats are only needed to prove it to people so that we could start actually abusing the hell it of it with no more proofs. What hegyak says. To Derakon: If it expands the "laboratory" too much for you, what about setting such "over the line TAS content" in the Demo tier? It is unique, no one did it before, it requires deep programming knowledge, it is interesting what will it end up with - all what people do demos for!
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.
Posted: 10/30/2013 7:49 PM
Quote
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
TASer of 2010 NES TASer of 2010 DS TASer of 2010 Arcade TAS of 2010 NES TASer of 2008 NES TAS of 2008 Funny TAS of 2008 TASer of 2007 NES TASer of 2007 Funny TAS of 2007
Derakon wrote:
It sounds to me like what is being proposed here is generating many different "universes" -- potentially googols or more of them depending on how picky you are -- until you get the one with the desired perfect initial conditions, and only then will you deign to enter the universe and start controlling things "normally".
I like your multiverse analogy. And to extend of that, I propose that the problem we have is that we do have to PICK a universe. Up to now, we've been living in a universe outside of our control. And the universe conditions have been decided by emulator coders making semi-arbituary decisions, certainly without thought as to what the ideal scenario is for TASing. We have the power to pick a universe and as such we are in fact picking a univserse. If we decide to stay in the comfortable universe that was given to us, we are still deciding that one over another. So why are we picking on vs another? And what criteria do we pick one? And by what criteria to we deem on to be cheating and not another?
It's hard to look this good. My TAS projects
Posted: 10/30/2013 7:54 PM
Quote
adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3572)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
TASer of 2010 NES TASer of 2010 DS TASer of 2010 Arcade TAS of 2010 NES TASer of 2008 NES TAS of 2008 Funny TAS of 2008 TASer of 2007 NES TASer of 2007 Funny TAS of 2007
<ais523> anyway, I think we should get a flashcart and program it to dump the initial memory of the NES to screen <ais523> to see what the initial NES memory actually looks like <ais523> the mappers make it more complex How about we do something like this, and do it many times and create a heat map? we could take a hex grid of data and represent it by a pixel per value and create an image. The color of that pixel will be hotter based on the number of times it was "on" If the heat map was essentially evenly colored, we could conclude that essentially any ram combination is theoretically possible. However if the image was "clumpy" then we know we need to be more skeptical of what's possible.
It's hard to look this good. My TAS projects
Posted: 10/30/2013 8:10 PM
Post subject: Re: Site policy regarding Alternative RAM stats on Power-up
Quote
Warp
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
adelikat wrote:
In more complex scenarios we may be able to do amazing things to a SNES game. We could have an entire program sitting in unitialized memory, and through memory corruption techniques maybe we could get the game to start executing at this point and completely take over the game (hypothetical, and unlikely, but certainly interesting).
I see little relevant difference between this and using just a custom ROM. It seems kind of pointless, especially in the context of this website, which is about completing games as fast as possible by playing them with superhuman accuracy. I really think that the more we deviate towards "let's run our own code in the console", the more we lose sight of the actual purpose of TASing: Namely, speedrunning. In other words, play the game, complete it as fast as possible. If you can affect the game via gameplay, that's par for the course. When you set values prior to even starting the game in order to get some effect, that's more dubious IMO. That's not playing the game anymore, nor is it speedrunning. Let's retain some purity to the concept of tool-assisted speedrunning.
Posted: 10/30/2013 9:31 PM
Quote
Patashu
He/Him
Joined: 10/2/2005
Posts: 4043
For the case of Blades of Steel, a super determined human who wanted the best possible real time world record would reset until uninitialized RAM gave him the perfect RNG for his route. Why is a TAS not allowed to pick the best possible starting RNG if a human is allowed to?
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
Posted: 10/30/2013 9:48 PM
Quote
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
  • An emulator should always emulate as accurately as possible. That means observing and emulating real-life RAM cell values. I don't think a TAS should have a say in that, especially since it's supposed to be just a list of external input states.
  • TASes are supposed to use the highest difficulty level. They aren't supposed to bypass that with a technicality.
  • In real life, achieving that particular state of RAM requires the environment (temperature, radiation, ...). A TAS is supposed to demonstrate the superior skills of an imagined "god player". If almost all that supposed god player does is waiting 100000 years for the right circumstances, it doesn't feel impressive at all.
  • It makes the TAS itself look weaker: it can only complete one specific version of the game, not all of them.
  • I also agree with henke37's post.
Posted: 10/30/2013 9:55 PM
Quote
Derakon
Joined: 7/2/2007
Posts: 3960
adelikat wrote:
I propose that the problem we have is that we do have to PICK a universe. Up to now, we've been living in a universe outside of our control. And the universe conditions have been decided by emulator coders making semi-arbituary decisions, certainly without thought as to what the ideal scenario is for TASing. We have the power to pick a universe and as such we are in fact picking a univserse. If we decide to stay in the comfortable universe that was given to us, we are still deciding that one over another. So why are we picking on vs another? And what criteria do we pick one? And by what criteria to we deem on to be cheating and not another?
This is definitely a valid point; there's nothing particularly special about the starting state that FCEUX uses. I would be curious to see what a normal NES starting state is like. The emulator has to use something, and it might as well be as plausible as possible. Regarding publishing such "selected initial conditions" runs under the Demo category, that seems reasonable. I'm having trouble convincing myself that such runs would be valid in other categories. As creaothceann said, it looks like the TASer is "playing a different game" from everyone else. EDIT: where it enters "cheating" for me is when the gameplay diverges from what normal play would look like due specifically to non-"random" events. That is, if your RNG is seeded from the initial state and you pick a specific initial state solely to get a favorable RNG, that's fine. If you pick an initial state that is unique, or nearly so, in triggering bugs or other game-logic breakdowns, then that's "cheating". If your initial state is sufficiently common that real-life play could occasionally stumble onto those bugs, then we're back out of "cheating". That's why I initially suggested the statistical-impossibility approach, which I grant is very fiddly and ill-defined.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Posted: 10/30/2013 10:27 PM
Quote
Demon_Lord
He/Him
Joined: 2/20/2011
Posts: 80
Location: Chicoutimi, Qc, Canada
I'm OK with it, as long as it's used only to seed RNGs. Especially not OK with jumping the instruction pointer to "uninitialized" memory.
1 2 3 4 5