Join debug room: while saving game, make soft reset game (don't need must correct frame but must not too soon or not too late). It'll create a corrupt save file can help join to debug room
Make best ending work: after make soft reset, just need change disk 2. In debug menu, select that option (I don't know what it's)
Notes
Setup before start: in Multi-disk Bundler need setup Valkyrie Profile (USA) (Disc 1) at disk 1, Valkyrie Profile (USA) (Disc 2) at disk 2
My movie file have wrong SHA1 because at previous it was created from only single disk 1 for my old run
I was tested both J and U versions. J version have less than scenes but U version have early make save game
After load corrupt save, all buttons config was changed. That's why I need change all them to default for can control to game
Chat
Long time ago, I had meet this glitch when load game save. But at that time, I don't know what's it, why it happened. Even I lost my game save (I had angry, that's why I'm still remember now), I just think I'm unlucky. Recently, I had seen FF7 can join debug room and make end game soon. I have think maybe that stage I was found is debug room. I have plan make corrupt game save, and it workd
This glitch possible do in real time, maybe can abuse to any speedrun (I'm not sure their rule have accept or not)
This's true best ending because noone must die, and kissssssss :)
ThunderAxe31: The strategy used in this run does entirely consist in corrupting the save file by turning off the console while saving. The advantage is given by the fact that the player resulted as standing in the debug room, which is a game location that is not supposed to be accessible during normal play. From this room it's possible to make use of a hidden feature that allows to play any cutscene of the game, in this case the the best ending sequence.
For comfirming the validity of the glitch used, I've tried to reproduce it on real PlayStation. While I failed to trigger the cutscene menu, I was still able to access the debug room. You can watch a recording of the attempt here.
For what concerns entertainment, I have to note that the glitch is performed just by the precision of the reset command and some movements in order to avoid getting softlocked in the debug room, which isn't particular notable from an aesthetic point of view. For the rest, the movie is almost all cutscene, with barely any interactions.
I thought using debug rooms to get to the end of the game wasn't allowed. Or is that only in the case of using codes to access the debug room? Is it acceptable here because save corruption was used to access the debug room?
I thought using debug rooms to get to the end of the game wasn't allowed. Or is that only in the case of using codes to access the debug room? Is it acceptable here because save corruption was used to access the debug room?
He didn't access it by using any kind of code. He accessed it by corrupting the SRAM.
In any case, I will do the necessary research for comfirming it, as well as looking that no other rules are broken.
Edit: I'll explain better. The Movie Rules are specifically referring to the usage of codes. Any kind of code or secret input sequence is forbidden, unless it's provided by the official game manual that comes with the physical game. For example, in Metal Gear Solid for PSX, there is a certain point of the game in which the player is required to retrieve a code present on the back of the original CD case of the game. Inputting this code is allowed.
SRAM exhibits data remanence,[1] but it is still volatile in the conventional sense that data is eventually lost when the memory is not powered.
While BizHawk does save the Memory Card files into a folder called PSX/SaveRAM, I have to note that the electronics of Memory Cards don't look like being battery backed. GB/C and SNES games instead feature a typical watch battery inside (not always for GBA games).
My point is that while "SRAM glitch" is accurate for GB/C and SNES games, it is not for PlayStation in general. However, I'm still unsure about which one would be a more appropriate label... Maybe something like "Memory Card glitch" or "EEPROM glitch"?
Impressive job with console verification of the glitch! I'll see what SRAM might mean in this case.
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.
feos pointed out in irc that this branch should be labelled as "save glitch", since it's the save function that is being interrupted.
This is slightly different from GB/C and SNES "SRAM glitch" movies, since these rely on uninitialized bytes in the Save RAM, which are supposedly 0xFF bytes. Instead, for the submitted movie, the glitched value that needs to be forced is a couple of 0x00 bytes, since it's the value that points to the debug room.
From what I can see by looking at the save file produced by BizHawk, it seems that the PSX does first create a 0x00 padded file, before starting to write in the actual data of the game save. In order to achieve the desiderable glitch, it's necessary to turn off the console before that the game writes the data for the location of the player, but at the same time it needs to be after that the game has written the main data of the save file, so that the game is still able to recognize it as a game save that could be loaded for playing.
To clarify, we have to use something different from "SRAM glitch" here, because for PSX, SRAM is a thing unrelated to save files, which are instead kept on flash memory cards, and that's what this run uses.
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.
SRAM exhibits data remanence,[1] but it is still volatile in the conventional sense that data is eventually lost when the memory is not powered.
While BizHawk does save the Memory Card files into a folder called PSX/SaveRAM, I have to note that the electronics of Memory Cards don't look like being battery backed. GB/C and SNES games instead feature a typical watch battery inside (not always for GBA games).
My point is that while "SRAM glitch" is accurate for GB/C and SNES games, it is not for PlayStation in general. However, I'm still unsure about which one would be a more appropriate label... Maybe something like "Memory Card glitch" or "EEPROM glitch"?
I would like to argue here that calling something "SRAM glitch" would be identifying something that abuses properties of SRAM in consoles that contain it.
There's a valid option to switch this entire "save corruption" movie class, where it causes a major skip glitch (which in turn doesn't have a game specific name), from "SRAM glitch" to "save glitch". The movie class was future proof in its name. The branch name apparently wasn't.
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.
