Posted: 9/30/2015 4:54 PM
Post subject: SNES-Tap: a SNES console debugger via EXP port
Quote
defparam
Joined: 9/30/2015
Posts: 2
Hey Guys, Some have you may or may not be aware of some of the SNES console work i've been doing using FPGAs. I set off on a mission last Jan to research the SNES EXP port to perform complete take over of the console to do things like load/save state, digital only graphics/audio output, etc... Since then I have created SNES-Tap which has the potential of doing all that and more. For more technical details on this device check out: http://forums.nesdev.com/viewtopic.php?f=12&t=13154 Here is what the device looks like: https://pbs.twimg.com/media/CMHYllaUkAAu17o.png Here is a current update of SNES-Tap showing its capability: https://www.youtube.com/watch?v=dE_q4EpsLco So long story short I want to continue work on this device and get it into key developers hands. Some of the items I want to tackle is load/save state on games like SMRPG, YI2, Starfox, etc... those games are particularly difficult because of the hardware co-processors. However, I also want to see how I can help out the TAS community. This device has complete access to read/write any system address, it knows the start of every frame and could be used as a meaningful tool for console verification. Let me know what you think, defparam
Posted: 9/30/2015 5:40 PM
Quote
feos
Site Admin, Skilled player (1255)
Joined: 4/17/2010
Posts: 11495
Location: Lake Char­gogg­a­gogg­man­chaugg­a­gogg­chau­bun­a­gung­a­maugg
NES TAS of 2011
WOW. Just WOW. This IS possible!
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: 9/30/2015 5:47 PM
Quote
Masterjun
He/Him
Site Developer, Expert player (2047)
Joined: 10/12/2010
Posts: 1185
Location: Germany
Exotic platforms TAS of 2020 Speedy TAS of 2018 PC TAS of 2018 Glitchy TAS of 2015 TASer of 2014 SNES TASer of 2014 TAS of 2014 SNES TAS of 2014 Funny TAS of 2014 Glitchy TAS of 2014 TASer of 2013 SNES TASer of 2013 NES TAS of 2013 SNES TAS of 2012 Funny TAS of 2012
So is that code you're writing being executed on the original CPU? Where the game is also being executed? Because if that is the case, then console verification wouldn't be valid anymore, would it? Even little things can change the outcome drastically.
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Posted: 9/30/2015 6:01 PM
Quote
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3827)
Joined: 11/30/2014
Posts: 2834
Location: US
GBA TASer of 2023 Homebrew TAS of 2023 Gameboy TASer of 2022 NES TASer of 2015
Wow that is really neat! I love seeing clever hardware related things. I hope you can get sound implemented somehow to get a true game/hardware state loaded. keep it up!
Posted: 9/30/2015 9:06 PM
Quote
defparam
Joined: 9/30/2015
Posts: 2
Masterjun wrote:
So is that code you're writing being executed on the original CPU? Where the game is also being executed? Because if that is the case, then console verification wouldn't be valid anymore, would it? Even little things can change the outcome drastically.
So i'm fairly new when it comes to the world of TAS but let me explain some potential configurations of this device that may satisfy for console verification. You have the device configured in a passive mode where if all you need is indication of when NMI occurs, or of when reading on the joystick port occurs then the FPGA can do that passively without injecting any code. If you do an active approach where say you have 1 small routine that is hooked at NMI, lets say for instance the routine adds an extra 20 bus cycles to every frame then you are looking at an overhead time of 6-8 microseconds lost per frame to overhead assuming a bus frequency of around 3MHz. (and of course the hook doesn't have to occur at every NMI).
Posted: 9/30/2015 9:22 PM
Quote
Masterjun
He/Him
Site Developer, Expert player (2047)
Joined: 10/12/2010
Posts: 1185
Location: Germany
Exotic platforms TAS of 2020 Speedy TAS of 2018 PC TAS of 2018 Glitchy TAS of 2015 TASer of 2014 SNES TASer of 2014 TAS of 2014 SNES TAS of 2014 Funny TAS of 2014 Glitchy TAS of 2014 TASer of 2013 SNES TASer of 2013 NES TAS of 2013 SNES TAS of 2012 Funny TAS of 2012
Then the passive mode should work in theory. The active approach won't work. Every single cycle has to be accurate.
Warning: Might glitch to credits I will finish this ACE soon as possible (or will I?)
Posted: 9/30/2015 10:35 PM
Quote
Demon_Lord
He/Him
Joined: 2/20/2011
Posts: 80
Location: Chicoutimi, Qc, Canada
I suppose it could be useful to get the state of a RNG and dynamically alter a TAS accordingly?
Posted: 10/2/2015 1:23 AM
Quote
True
Editor, Player (69)
Joined: 1/18/2008
Posts: 663
Actually, this could be useful potentially for Super Metroid sync if my clock inject method doesn't work, or perhaps in addition to that. Want to discuss on IRC?
true on twitch - lsnes windows builds 20230425 - the date this site is buried
Posted: 10/7/2015 6:40 AM
Quote
True
Editor, Player (69)
Joined: 1/18/2008
Posts: 663
Actually, I thought of something else this could be useful for. Right now the fast SMW run does not verify on console. We don't know for sure what is going on but we're probably hitting a register that isn't being emulated properly. Looking at the controller on the LA I see that we're getting past some controller register so the main exploit is working - we're getting stuck some time past that. Perhaps some work could be done so we can figure out what is going on in this state (see PC, etc) and improve / fix emulation. This may require a combination of a replay robot and this board. I was originally going to hook up a logic analyzer to A BUS but maybe this could be used instead?
true on twitch - lsnes windows builds 20230425 - the date this site is buried