1 2
336 337 338 339
Posted: 6/21/2020 7:19 PM
Quote
jlun2
Skilled player (1742)
Joined: 9/17/2009
Posts: 4985
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
GBA TASer of 2010
I can't see the discord link message. What was it?
LLCoolDave wrote:
This seems to be competing for the "Worst looking TAS of 2011" Award.
Posted: 6/21/2020 11:14 PM
Quote
Patashu
He/Him
Joined: 10/2/2005
Posts: 4045
Basically that the ABC Trials got solved in 0x A Presses. Link to video
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: 6/24/2020 3:26 PM
Quote
Personman
Other
Joined: 4/20/2008
Posts: 465
So I was reading this neat article about someone who found a remote execution vulnerability in Morita Shogi 64, and it contains this intriguing paragraph:
For example, Super Mario 64 is fully decompiled so I took a quick look and was able to find a write to an out of bounds pointer if sSoundMode (offset 0x1d1, 1 byte) is too large, which can be triggered by pressing the sound option box on the file select screen. That can be used to NOP out some code in the title screen renderer, but I gave up trying to exploit that - maybe someone reading will be interested in the challenge... if you could do it, you could potentially make a payload that patches Mario's colour to green to 'unlock Luigi' on a real cartridge, a feat people have been attempting since its release in 1996!
I have no idea if this will actually turn out to be exploitable, but it seems like folks here ought to be made aware of it..
A warb degombs the brangy. Your gitch zanks and leils the warb.
Posted: 6/24/2020 7:51 PM
Quote
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3824)
Joined: 11/30/2014
Posts: 2832
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
Cool challenge, the depth of knowledge needed for SM64 is really incredible.
Posted: 7/29/2020 5:59 PM
Quote
Tompa
Any
Editor, Expert player (2216)
Joined: 8/15/2005
Posts: 1942
Location: Mullsjö, Sweden
NES TAS of 2018 SNES TASer of 2017 SNES TAS of 2017 NES TAS of 2014 GBA TASer of 2011 GBA TAS of 2011 SNES TASer of 2010
Link to video
Posted: 7/30/2020 12:56 AM
Quote
Patashu
He/Him
Joined: 10/2/2005
Posts: 4045
Notably, this strat was what the 120 star TAS update was stuck on for (2?) years, and now that it's finally done progress can continue. And what a spectacle it ended up being!
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: 9/15/2020 8:34 AM
Quote
Synx
Joined: 3/17/2009
Posts: 496
Tompa wrote:
Link to video
This is HYPE! I can't remember the last time I got this excited watching sm64 TAS.
Posted: 11/5/2020 12:00 PM
Quote
Ramzi
Joined: 3/25/2004
Posts: 459
I recently saw this video which offers a $1000 bounty for a glitch replication demo: https://www.youtube.com/watch?v=aNzTUdOHm9A My first reaction was to attempt to fuzz test this to replicate the glitch. If we can put a watch on a height variable, then fuzz test until that height variable is met... Unfortunately, I am unfamiliar with the emulator tools to do this. I would assume the fuzz tester would have to be programmed in Lua, and I'm not a Lua programmer. I also don't know where the height variable is. And even if I had those two pieces of information, I wonder how slow it would be to fuzz test this. That is, does the fuzz testing have to occur in real time, rendering the graphics and everything? Or is it possible to run the game logic way faster than normal execution speed, and even forego rendering the graphics? How hard do you think it would be to claim this $1000 bounty through fuzz testing? Thanks.
Posted: 11/5/2020 3:44 PM
Quote
Ramzi
Joined: 3/25/2004
Posts: 459
Another idea I had, instead of fuzz testing, is to replicate the video of the glitch by finding which inputs can frame-by-frame match the one video of the glitch occurring. Sure, there might be some prerequisites for the glitch which might not be met, but I would think there is a fairly good chance of replicating the glitch by matching the frames alone.
Posted: 11/5/2020 3:49 PM
Quote
psx
Joined: 9/26/2020
Posts: 24
Ramzi wrote:
Another idea I had, instead of fuzz testing, is to replicate the video of the glitch by finding which inputs can frame-by-frame match the one video of the glitch occurring. Sure, there might be some prerequisites for the glitch which might not be met, but I would think there is a fairly good chance of replicating the glitch by matching the frames alone.
Link to video Something like that has been tried, though I would note the person in question (is in the comments of the video) who experienced the glitch said their cartridge was askew, which seems like the most likely answer.
Posted: 11/5/2020 4:28 PM
Quote
Ramzi
Joined: 3/25/2004
Posts: 459
After rewatching the video you just linked, I'm wondering how faithful of a replication the frames are. The videos look very similar, of course. But even a slight difference in the camera angle could be responsible. I'm researching this now, and I don't think it is a matter of crooked cartridge. This video shows the upwarp without a hanging ceiling: https://www.youtube.com/watch?v=VV1dzNzRYkU
Posted: 11/5/2020 4:49 PM
Quote
Xander
He/Him
Joined: 12/31/2016
Posts: 17
Location: Canada
Ramzi wrote:
This video shows the upwarp without a hanging ceiling: https://www.youtube.com/watch?v=VV1dzNzRYkU
That video is done on a ROM Hack which has extra anti-softlock code. It is unrelated. The pannenkoek video didn't aim to replicate it frame by frame but to demonstrate what would need to happen in order for the upwarp to occur - it shows that Mario didn't warp to the ceiling but a bit in Mario's height appears to have flipped. No sequence of inputs alone is going to cause that to happen. A lot of people have looked at this in depth, if you want to talk with any of those people I suggest joining the SM64 TASing discord server https://discord.gg/ECskvyF
Super Mario Galaxy/64 TASer
Posted: 11/5/2020 4:54 PM
Quote
Ramzi
Joined: 3/25/2004
Posts: 459
Why do you say "No sequence of inputs alone is going to cause that to happen"? Why couldn't a sequence of inputs cause that bit to flip?
Posted: 11/5/2020 6:45 PM
Quote
Xander
He/Him
Joined: 12/31/2016
Posts: 17
Location: Canada
Controller inputs don't cause bit flips. The people who decompiled the game would've known that a long time ago if they saw any possibility for it in the code. If someone were to brute force every combination of inputs that lasts 9 seconds and prove me wrong I would be very impressed.
Super Mario Galaxy/64 TASer
Posted: 11/5/2020 7:06 PM
Quote
Mitjitsu
He/Him
Banned User
Joined: 4/24/2006
Posts: 2997
TAS of 2007 N64 TAS of 2007
I tried messing about with it for a couple of hours when the video initially came out and had no success, and people even tried replicating DOTA's entire inputs from his stream and they couldn't do it. Like others have been saying it could be crooked cartridge or DOTA not playing with a legitimate ROM.
Posted: 11/5/2020 7:14 PM
Quote
Ramzi
Joined: 3/25/2004
Posts: 459
From what I've seen, only one person attempted a frame-by-frame recreation, and only got 30 frames in, out of 300, and that was years ago. So I'm skeptical that DOTA's entire run was replicated. > Controller inputs don't cause bit flips. Of course they do. Just think about how any game works. If you have 4 bombs in Zelda, and you press B, suddenly you have 3 bombs. That caused a byte to change. > The people who decompiled the game would've known that a long time ago if they saw any possibility for it in the code. It's hard to read code and to tell how areas of memory can be affected.
Posted: 11/5/2020 7:57 PM
Quote
nim
He/Him
Joined: 11/5/2020
Posts: 8
> Of course they do. Just think about how any game works. If you have 4 bombs in Zelda, and you press B, suddenly you have 3 bombs. That caused a byte to change. Bytes changing aren't bitflips. The instruction that decrements a byte is very different to the instruction required to flip a particular bit in a floating-point number, just because they both involve bytes changing doesn't mean one can lead to the other > It's hard to read code and to tell how areas of memory can be affected. No. Say you have the following code: 
Language: c
if (gPlayer1Controller->buttonPressed & A_PRESSED) {
    gMarioState->action = ACT_JUMP;
}
There is no possible way for this code to affect any area of memory other than gMarioState->action without external forces acting on the console. Code is a fixed set of instructions for a processor to evaluate and in normal execution, the processor should never deviate from what the instructions are obviously telling it to do. There is no path to the DOTA upwarp in the code, and therefore it could not have occurred under normal circumstances.[/code]
Posted: 11/5/2020 8:05 PM
Quote
Ramzi
Joined: 3/25/2004
Posts: 459
> Bytes changing aren't bitflips. The instruction that decrements a byte is very different to the instruction required to flip a particular bit in a floating-point number, just because they both involve bytes changing doesn't mean one can lead to the other Then how do we know that the upwarp requires a bitflip rather than a byte change? Sure, he replicated it with a bitflip, but couldn't a byte change cause the same value in memory? > There is no possible way for this code to affect any area of memory other than gMarioState->action without external forces acting on the console. Of course THAT code would be known not to explicitly change a memory value, but if there is some kind of game loop which checks Mario's position on each tick and updates memory accordingly, then jumping of course modifies memory.
Posted: 11/5/2020 8:09 PM
Quote
nim
He/Him
Joined: 11/5/2020
Posts: 8
Increasing a byte by 2 is a different instruction to setting it to 3. If the game is programmed to add Mario's upwards velocity to his position while jumping every frame, there's no way for it to add 2000 to his position without either his velocity actually being 2000 or some external corruption inside the processor. Processors are designed to do what the code says, and that can't magically change without some external interference. It is true that if there were some code that could update an arbitrary place in memory or something it might be able to change Mario's position, but no such code exists in the game.
Posted: 11/5/2020 8:13 PM
Quote
Ramzi
Joined: 3/25/2004
Posts: 459
> without either his velocity actually being 2000 How do we know there isn't some glitch which causes his velocity to be 2000 for a frame? That wouldn't be readily easy to detect in the code. Like if the Bob-omb explodes and Mario is directly above it, some wonky addition occurs. I'm not seriously suggesting that; I'm just trying to be illustrative. > or some external corruption inside the processor. How do we know that such a corruption isn't deterministic? That is, it's not due to cosmic rays, but would occur faithfully in any emulation of that processor?
Posted: 11/5/2020 8:23 PM
Quote
nim
He/Him
Joined: 11/5/2020
Posts: 8
> How do we know there isn't some glitch which causes his velocity to be 2000 for a frame? Well, that's the thing; we've exhausted any possibility of this happening without external influence, because if it could happen with the processor doing what it was supposed to, the game would do exactly what its code says to, which leaves no possibility for any type of glitch like this. > How do we know that such a corruption isn't deterministic? Because that isn't how processors work? The only way I can think of something like what you're describing is a design flaw in the processor, instances of which do exist (early N64 processors had a bug when two multiply instructions were executed consecutively), but this is extremely unlikely. Even if another CPU flaw did exist, to be completely undetected until now is ludicrous. The N64's CPU was marketed as a PC processor, and for such a serious design flaw to go completely undetected throughout all the factory testing, home and console usage in the 90s, all the way up to 2020 with the sole exception of one speedrunner in one race, is really ridiculous. It should also be noted that DOTA's N64 was purchased and no abnormalities have been found in its processor's execution, which rules this out pretty conclusively.
Posted: 11/5/2020 8:38 PM
Quote
Ramzi
Joined: 3/25/2004
Posts: 459
> we've exhausted any possibility of this happening without external influence How? > because if it could happen with the processor doing what it was supposed to, the game would do exactly what its code says to, which leaves no possibility for any type of glitch like this I am presuming the processor works correctly and it does exactly what the code says to, but there is an explanation in the code which causes the upwarp. I'm not convinced the code has been analyzed and internalized by human minds comprehensively enough to rule out the possibility that this is a "legal" result following the code's proper execution. > The only way I can think of something like what you're describing is a design flaw in the processor, instances of which do exist (early N64 processors had a bug when two multiply instructions were executed consecutively), but this is extremely unlikely. It is more unlikely that cosmic rays modified the hardware in his favor in this manner. > Even if another CPU flaw did exist, to be completely undetected until now is ludicrous. It is more ludicrous to think cosmic rays modified the hardware in his favor in this manner. > The N64's CPU was marketed as a PC processor, and for such a serious design flaw to go completely undetected throughout all the factory testing, home and console usage in the 90s, all the way up to 2020 with the sole exception of one speedrunner in one race, is really ridiculous. It has happened before: https://en.wikipedia.org/wiki/Pentium_FDIV_bug That article says: "The severity of the FDIV bug is debated. Though rarely encountered by most users (Byte magazine estimated that 1 in 9 billion floating point divides with random parameters would produce inaccurate results)" So it would be very rare, especially in a video game where you are not programming a custom math program to run against the processor. The article goes on to give an example of the math error: 1.333820 vs. 1.333739 saying: "the value returned by a flawed Pentium processor in certain situations is incorrect at or beyond four digits". So were there such a minor flaw in a video game, it would be unlikely to be detected. Personally, I don't think it's a flaw in the processor, and I don't think it is a minor math error. I think it is a deterministic glitch that is replicable given certain legal inputs and proper code execution, which causes a large change in a value, not a minor one. > It should also be noted that DOTA's N64 was purchased and no abnormalities have been found in its processor's execution, which rules this out pretty conclusively. Then what alternative explanation is there? Cosmic rays? Doubtful. I've heard a lot of talk about crooked cartridge, but I've also read that no one has been able to replicate the glitch with crooked cartridge. Contrast this with the Ocarina of Time crooked cartridge glitches, which were easily replicable.
Posted: 11/5/2020 8:48 PM
Quote
jongyon7192p
Joined: 8/13/2014
Posts: 14
> How do we know there isn't some glitch which causes his velocity to be 2000 for a frame? Then Mario would move forward 2000 units, dumbasssss!! /s (And then his q-steps will get cancelled by OoB and he will bonk and none of this upwarp thing that happened would happen. Trust me, I would know the subframe processes that-- Okay, Nim would know, not me.)
DeRockProject: the Life-changing Project (TAS is perfection in this imperfect world. TAS is the answer to the longest math problems we have, called video games. TAS perfects worlds. TAS is god. TAS is the future. TAS needs us. Let it govern us. All hail TAS.)
Posted: 11/5/2020 9:01 PM
Quote
jongyon7192p
Joined: 8/13/2014
Posts: 14
> It is more ludicrous to think cosmic rays > Then what alternative explanation is there? Cosmic rays? Doubtful. Okay, look, we're SM64 Experts, we aren't a bunch of dumb crackpot youtube commenters. We know it's not cosmic rays. It's not crooked cartridge as much as it's just hardware malfunction from like, an old faulty cartridge or something. What you need is a link to that darn gdoc that we should've linked you like 20 messages ago. https://docs.google.com/document/d/1mEBR-fNnYnvKwmDej1fOaZ17XDKDMxdUnQyHOcMjrb0/edit#heading=h.ek46c5u9vwi7 Quate, one of the oldest SM64 Experts, decided to start investigating another anomaly that might be tied to the Upwarp, recently. Here's what he has so far. Actually, I haven't read the latest stuff tbh.
DeRockProject: the Life-changing Project (TAS is perfection in this imperfect world. TAS is the answer to the longest math problems we have, called video games. TAS perfects worlds. TAS is god. TAS is the future. TAS needs us. Let it govern us. All hail TAS.)
Posted: 11/5/2020 9:26 PM
Quote
nim
He/Him
Joined: 11/5/2020
Posts: 8
Nobody actually thinks it's cosmic rays, that's a theory completely originated and propagated by youtube comment sections. > I am presuming the processor works correctly and it does exactly what the code says to, but there is an explanation in the code which causes the upwarp. I'm not convinced the code has been analyzed and internalized by human minds comprehensively enough to rule out the possibility that this is a "legal" result following the code's proper execution. Have you seen https://github.com/n64decomp/sm64 ? Completely ruling out software for things like the upwarp has been one of the main motivators for this project. SM64 isn't a very complex game (its code is very modular and predictable), and people have overall spent many hundreds of hours trying to find the upwarp glitch in the code (and thousands of hours besides upwarp searching). Given that there are also plausible (non-cosmic-ray) explanations for how it could've occurred due to external forces, it's just not feasible that it could be something in the code. > I've heard a lot of talk about crooked cartridge, but I've also read that no one has been able to replicate the glitch with crooked cartridge. Contrast this with the Ocarina of Time crooked cartridge glitches, which were easily replicable. Similar to cosmic rays, nobody who actually knows anything on the matter thinks that this could've been caused by cartridge tilt. Cartridge tilt has completely different and easily recognizable effects on the game. Some feasible explanations include: - Some undiscovered defect in the console; the google doc jongyon linked shows how one SM64 speedrunner's N64 is extremely susceptible to strange upwarp-type glitches, most likely due to some kind of defect somewhere. - Electrical issue: one possible way the upwarp might've occurred is if the Y translation part of Mario's animation values, which IIRC are DMA'd from ROM constantly, got corrupted. If I'm remembering correctly, in the original twitch video from DOTA you can hear a noise of some sort from DOTA's house when the upwarp happens, so it seems plausible that some electrical surge might've interfered with the N64's reading from the cartridge for just a moment, and it just happened to corrupt that value. There are probably more equally plausible explanations that I don't remember, none of which involve a valid path through the code without external corruption. Overall, I just don't think it's plausible that the upwarp could occur in-game. And as someone who has personally spent orders of magnitude more time staring at SM64 code than is probably healthy, I can say pretty definitively that it's just not possible without anything short of ACE (which is also almost definitely not possible without Wii VC).
1 2
336 337 338 339