Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
It uses not the regular SNES-controllers, but the fictive 16-button SNES controllers that uses the extra 4-bits of data as buttons, while a normal SNES controller only uses 12-bits for buttons.
There's no need really to support that though since it's only used for this very specific thing, and it doesn't technically need to be used for that either with some code changes in the ASM code.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
Alyosha wrote:
Oh that's cool! Is the only reason there is no music because it's not in the file? Or am I missing something else that needs to be implemented?
It's not in the file at all, and the way it's coded is that it uses SNES controllers and all 16-bits of them and that wasn't supported as an input device in SubNESHawk as far as I could see.
It uses SNES controller mostly just because it worked well with the hardware replay setup, not because it was actually needed I think. So it should be possible to just recode the PCM player to use regular NES controllers. I'll see if I can get some time to take a look at that and submit a new movie with music included.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
I took some time and managed to convert the AGDQ2017 SMB3 ACE payload we used that does the DPCM glitching in 1-1 to lead into full total control. It's not the final version that was shown but it's mostly the same.
Wasn't too easy to convert though since I had to first convert the inputs from the binary format used for the hardware replay and then go in and manually resync inputs for every lag frame and frame boundary that didn't match up, but finally it worked :)
Here's the bk2:
http://tasvideos.org/userfiles/info/52514549789799992
Pretty cool to see it working at least!
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
Wow, great job!
It's really cool to finally have this feature available in BizHawk.
Not only will it help bringing runs that uses subframe input to abuse the DPCM-glitch workaround in games, but it'll also enable faster ACE payload data transfers for future run that would use that.
I'll have to check it out when I can and try to convert the runs I've done for SMB3 and MM1 for AGDQ so people can check it out in an emulator if they wish.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
Dwedit wrote:
Regardless of anything else, adding something that connects to the system bus is more like adding a Game Genie than a controller.
Agreed, the fact is that a device sitting in the expansion port can take control over the CPU pretty much at any time by hijacking and overriding the bus at the right time. There's no need for any kind of exploit in the game at all.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
You can add Super Metroid to the list as well.
Edit:
Oh, and NES Open Tournament Golf as well (has a way to get into an ACE state using the NES DPCM glitch).
There are probably a bunch more NES titles that allow this using the same glitch as well, but none that I have confirmed it for.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
MUGG wrote:
AGDQ spoiler How did you achieve ACE in 1-1?
As been mentioned it's the same method as used in the title screen ending glitch.
It abuses the fact that SMB3 reads input multiple times per frame and compares the reads until they match to get around the DPCM bug in the NES.
So by just sending alternating inputs each read the game will get stuck in the controller reading loop for as long as these inputs are alternated, causing all kinds of bad behaviour with NMI re-entering on top of itself corrupting the stack. (MMC3 IRQ for the statusbar split also plays a part in SMB3).
In the end this makes it possible to trick the game into excuting RAM contents as code, and in RAM the koopa shells was used to write a small loader that reads inputs, stores it in RAM and eventually executes those inputs. And from there on total control is achieved.
When I get the code cleaned up a bit, I'll post all the source code and tools used for the AGDQ 2017 ACE.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
feos wrote:
ais523 wrote:
FCEUX can handle them if they're input via Lua (and, although quite possibly not perfectly accurate, is accurate enough to emulate the run in question); however, there's no way to specify the input in question in an input file/recording.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
Me and Sniq finally got our semi-optimized 13% Charge/Speed Route Test TAS done. Final time was 50:41, and this can probably be pushed below 50 with further optimization.
There's a few major mistakes like not blowing up the tube when passing it the first time and some other minor details that can be improved, but the route itself is probably very close to final.
Early inputs for this test was borrowed from Taco's Any% WIP, and some rooms in norfair are heavily inspired by Namespoofers 14% Speedbooster TAS.
Any ideas or suggestions for improvements are welcome.
LSMV:
http://tasvideos.org/userfiles/info/30904919119106655
Encode:
https://www.youtube.com/watch?v=moIWUc_HoQM
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
I agree with that we shouldn't have multiple branches of the same category where items collected is the only difference, so ideally we should only end up with one low% (13%) run.
This run should in my opinion be a run that is not using the overflow glitch since this run would follow the same set of "rules" as the currently existing low% runs that exist on the site. These rules being that it does not use any "major glitches" to complete its goal, different from the "game end glitch" 2% run (which can be considered low%, but uses major glitches).
This all obviously comes down to if we would consider ammo overflow a major glitch or not in this situation, and I'd say that it is. It practically gives you infinite ammo and makes anything in the game after it into "super missile spam everything".
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
boct1584 wrote:
Hey Total, do you have another link to your 13% proof-of-concept? I tried to show the VOD link to some friends and it either purged or you deleted it (Twitch doesn't say which.)
I forgot to highlight it so it seems twitch has eaten it, but that proof-of-concept is now quite outdated and there's a completely new route with some new tricks in it that we're working on. Hopefully it'll be done somewhat shortly and I'll make sure to post both a video and a lsmv of it :)
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
Warp wrote:
In other words, for example, tasbot takes total control of a SNES console, which is connected to a NES console, and proceed to TAS a game as normal on the NES. Tasbot itself could be disconnected (if possible) on camera to demonstrate that it is indeed the SNES which is TASing the NES game.
This is a pretty cool idea, and something I think would be very possible without even any extra hardware apart from a custom made cable between the SNES and NES controller ports.
A SNES should certainly be fast enough to be able to send inputs to a NES using manual polling register reads and writes.
There would be a limit ofcourse to fit the controller data in SNES RAM, but 128k should be enough for a pretty decent TAS.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
ais523 wrote:
(One potential problem: the NES would need to be able to write the controller wires as fast as the other console was trying to read them, assuming we're not putting extra hardware in between. It might be necessary to use faster consoles to control slower ones.)
I quickly looked at this and from what I could tell counting clock cycles the NES is just fast enough to be able to respond in time to the SNES autopoller timings using cycle accurate code.
So provided that the SNES reads the controllers sequentially it should be able to provide inputs for four controllers per frame.
(This hasn't been tested though so it might be inaccurate, I'm gonna see if I can write some code and put on my NES flashcart to verify)
After the payload is written to the SNES this can be increased a bit since it's then possible to just use the controller ports as a general serial link and read/write as fast as the consoles can handle.
Another thing worth considering is using a Famicom and hook up the expansion port (or use the NES expansion port, but it has a pretty strange connector afaik).
Using the expansion port should make it possible to increase the data rate a bit because of a few more I/O:s.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
I did some debugging on this shinespark glitch and what happens is that a code pointer (7E0A58) gets set to the wrong value while in the shinespark pose. Normally when you start a shinespark that pointer gets set to use code that deals with shinesparking.
But when we start a shinespark at the same time as the "knockback timer" (7E18AA) runs out and while the "knockback direction" (7E0A52) is above zero, the game will run code to clean up the knockback state.
This code runs after the shinespark initiation code and one of the things it does is reset the code pointer (7E0A58) to point to "normal movement code". This then makes the game not really able to handle the "waiting to start a shinespark" pose and samus will just sit there.
I haven't yet fully researched why the shinespark counter sticks to 1 when you shinespark in this pose after the counter first have run to 0, but I guess it's a glitch caused by shinesparking when you're not supposed to be able to.
Also, after learning more about this glitch and talking to Taco we learned that this is now also possible:
http://dehacked.2y.net/microstorage.php/info/272343641/slopespark.smv
Turns out all you need is a slope and something to knock you into it :)
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
I did some test with this and not surprisingly it's possible to get the double spark by getting stuck with the feet inside a respawning block and then get hit by an enemy while having a shinespark ready. Not sure if this is useful anywhere but at least it's one more option to activate it.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
I guess one thing you could try is to manually get something pushed to the stack and run RTL (6B) and hope it takes you somewhere useful.
Other than that I can't think of anything right now besides what you've already tested.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
Cpadolf wrote:
Thanks total!
Twocat, do you know which Y position you were at in the video Dessyreqt posted? The best one I've been able to find so far is a small platform at Y=9451, where you can do a quick jump to reach a door transition to the tube room.
The position in that video should be around X=-300 and Y=9307.
It's pretty much the green "step" blocks to the left of the block you describe at 9451. The reason we didn't stop at the blue block at 9451 and then jump right is that it would be very risky to do in realtime compared to going left and then hitting a transition there.
For a TAS though, I'm pretty sure landing on that blue block at 9451, X-raying and then jumping right and hitting that door transition from behind is the best bet.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
Cpadolf wrote:
Thanks! Also, does anyone know if the lua script to see block positions OoB is available in Bizhawk, or if it would take a lot of work to convert it?
I had a port of the script to Bizhawk that I've uploaded:
http://tas.speedga.me/Super%20Hitbox%202%20Bizhawk.lua
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
There might be some hope for this for arbitrary code execution actually.
I found yesterday that if you hold up to X-Ray up, it will start shifting in bytes that's certainly not 00FF or FF00. They seem to be the same every time so it could be data from ROM but I'm not sure, it was late so didn't have time to research much more.
I did manage to use it to trigger something funny though. By standing at the exactly right pixel I got it to set both the escape sequence trigger and also reset the gamestate so when loading a save the intro plays.
http://www.twitch.tv/tewtal/c/3980860
Doing this will also delete your missiles and make your item percent one percent lower, so doing this would result in 5% if you do it with 6% :)
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
I should add that this glitch using X-Ray OOB is something Kejardon found 9 years ago that someone mentioned to me and I did some research on.
I haven't done any debugging or anything yet on this but the effects of it is that when you go down a few screens OOB, X-Ray will start overflowing memory and start overwriting all kinds of thing in RAM. The amount overwritten seems to be affected by the Y-position, so the further down you go, the more gets overwritten.
There's some other quirks as well that needs to be researched with it, like it will write different patterns depending on which way to X-ray. Also holding up for a while will also affect the data it writes.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
I do think doing a real RBO run would be cool though.
I was actually thinking about a similar idea recently where we'd use arbitrary code execution to just chain the boss fights together in a big reverse boss rush, ending with bomb torizo. And when finally leaving his room you'd end up at the ship with the planet exploding or something like it.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
Derakon wrote:
I'm pretty sure that Space/Time can toggle the bit that determines if the planet is exploding. At least, I'm nearly positive I've seen a run that "wins" by triggering the escape sequence without ever going to Tourian; if you can set the explosion bit to 1, then you can probably set it to 0 as well by triggering the glitch in different circumstances.
The place where I did the reset-items/bosses glitch on console is the side area from the Old Tourian Escape Shaft (where you have to freeze some monsters, then run over them to charge a shinespark). Since you'd have to do space/time anyway to stop the planet from blowing up, you might as well reset the items at the same time.
Actually, just triggering space-time in pretty much any place or any way will reset the items and also disable the planet explosion sequence since it will overwrite those bits with 0 in most cases. There's a quite specific way you need to use space-time to turn it back on though.
I'm not sure if that will deactivate the timer though, so it's possible that you will have to use space-time to escape the room after killing MB before the timer is set.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
Cpadolf wrote:
Think I got it now. Don't know if TASvideos will actually accept it but it should be ready to be submitted once the ending has been triggered. I think amaurea and total should be co authors for developing and executing the method to get control over the game and triggering the ending considering how big of a part it is to the run.
Yes, this was great, amazing work with this run!
I had to add two extra frames of inputs to make sure Samus wasn't traveling upwards when the shot is fired, and then five more frames for the inputs for triggering the ending. Normally it should have been three frames only for those inputs, but for some reason the game decided to only run the code that updates beams every other frame this time, so I had to insert two blank frames.
Here's the final lsnes movie file:
http://tas.speedga.me/Super%20Metroid%20Glitch%25.lsmv
I couldn't find a way to modify the rerecord count though, so for now it will show only 1 rerecord.
Experienced Forum User, Published Author, Player
(38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
Cpadolf wrote:
BTW does the Y position have to be exact as well or is it just the X position?
Yes, both X and Y positions have to be exact, and you should let go of the X-button one frame before you hit that position so it releases the charge at exactly that position. If the game just completely freezes then when you're at the right position, it's all setup properly.
EDIT:
I uploaded a Bizhawk 1.6.0 watch-file with the memory-addresses to: http://tas.speedga.me/smglitch.wch