I was going through the list of console-verified titles, and I noticed that there were only N64 and NES games available on the list. I understand somewhat (I'm a junior in Elec. Eng.) that a microcontroller of some sort is used to feed output from the computer to the console, but is there a particular reason why no one has made a SNES version?
The reason I ask is because for my senior design project, I would like to construct one, if possible. If someone has tried and come to the conclusion that it would be impossible, I would love to find out why, and see if perhaps there's something that was overlooked! Furthermore, I think it would be spectacular to see these TASes played back on the missing link of Nintendo consoles.
I was going through the list of console-verified titles, and I noticed that there were only N64 and NES games available on the list. I understand somewhat (I'm a junior in Elec. Eng.) that a microcontroller of some sort is used to feed output from the computer to the console, but is there a particular reason why no one has made a SNES version?
I have heard that SNES version already exists (one just needs to expand the NES version shift registers from 8 to 16 bits).
I haven't heard of any attempts at verifying runs with that one tho.
The problems with SNES verification:
- The SNES has autopoller, which most games use, so you have to get lag right[3].
- Bsnes-based SNES emulators (lsnes and Bizhawk) are very recent, not many runs yet.
- SNES is absolutely impossible to perfectly emulate the state evolution of[1]. AFAIK, neither NES nor N64 have the same problem[2].
How severe those limitations are remains to be tested.
DiscoRico wrote:
The reason I ask is because for my senior design project, I would like to construct one, if possible. If someone has tried and come to the conclusion that it would be impossible, I would love to find out why, and see if perhaps there's something that was overlooked!
The hardware is certainly possible to build. As to if any runs sync, even with current cutting-edge emulators remains to be seen.
For exporting data for this kind of thing was exactly why I implemented on_snoop Lua callback to lsnes (which was then later copied to Bizhawk).
[1] The SNES state evolution is not deterministic. It is somewhat random (due to the two crystal oscillators).
[2] You may not know the initial state of these consoles, but if you know the state of the console and the input in meantime, it is theoretically possible to compute the state of the system at any later time.
[3] As very good example of getting the lag really wrong and still managing to sync (due to lack of autopolling), take a look at those SM64 runs... The runs are much slower on console than on emulator.
I have plans to build a SNEBot, I just haven't gotten to it yet. The biggest thing holding me back right now is my lack of a workspace, but that should be changing soon.
The hardware to build a SNESBot would be a simple expansion of the NESBot.
Ilari wrote:
I have heard that SNES version already exists (one just needs to expand the NES version shift registers from 8 to 16 bits).
The SNES controller is an NES controller with 4 more buttons. The shift register they used only supports 8 bits, so they tacked on a second one to support the extra buttons. The interface is the same (power, ground, clock, latch, and data). SNES games then just poll the controller for 12 bits, while NES games only poll for 8 bits. Don't quote me on this, but I'll bet if you swapped out the plug on a SNES controller for an NES plug, it would work fine and the extra buttons would just be ignored.
I hadn't tried building the bot back when I was more active with the NESBot because I believe I ran out of pins on the Arduino. Since then I have pursued other microcontrollers and have a new design in mind.
As for getting movies to sync, that is a totally different problem. As Ilari described, consoles are hard to emulate perfectly accurately. Things like initial state and lag can ruin games chances of syncing. When I first started playing with the NESBot I used SMB1, a game that is easier to emulate correctly. I'd suggest picking a game that is easier to emulate on the SNES to have the best chance of a movie syncing. I'm not actually sure what that is, but I'm sure someone else here has some suggestions.
Could you please explain what on_snoop does? I'm not exactly extremely familiar with any of special Lua functions in any of the emulators, aside from simple scripts that turbo during cut scenes, etc.
Also, what is autopolling? If the name is anything to go by, I would think it's something like a system by which the SNES receives input only at a fixed periodic rate. Is this the case?
EDIT:
Also, what is the functionality of the shift register in terms of registering input of the buttons? 8 bits on the NES controller correspond to? Up, down, left, right, A, B, Start, Select, I assume. 4 more bits for SNES adds LT, RT, X, and Y. Does this mean that NES and SNES both use some form of PWM or PPM to deliver button input?
Also, what is the functionality of the shift register in terms of registering input of the buttons? 8 bits on the NES controller correspond to? Up, down, left, right, A, B, Start, Select, I assume. 4 more bits for SNES adds LT, RT, X, and Y. Does this mean that NES and SNES both use some form of PWM or PPM to deliver button input?
The shift register used is the 4021, a parallel to serial shift register. I'm sure there are plenty of descriptions of this kind of shift register available, but basically the chip takes 8 bits and outputs them over one pin. A game toggles the latch pin which causes the chip to read the bits and remember them. Then the game toggles the clock pin 8 times. The shift register outputs one bit at a time, and changes which bit it is giving each clock. For an SNES game, the game would toggle 12 times, and the two chips combined would supply 12 different bits.
The SNES controller is an NES controller with 4 more buttons. The shift register they used only supports 8 bits, so they tacked on a second one to support the extra buttons. The interface is the same (power, ground, clock, latch, and data). SNES games then just poll the controller for 12 bits, while NES games only poll for 8 bits.
From reading bsnes autopoller code, it actually polls for 16 bits, not 12. The extra 4 bits appear to be controller identification bits (which are 0000 for standard gamepad).
micro500 wrote:
As for getting movies to sync, that is a totally different problem. As Ilari described, consoles are hard to emulate perfectly accurately.
I claim perfect emulation (ignoring initial state) is not possible even in theory for SNES. Even extracting the complete circuit model and running it in circuit simulator wouldn't be enough.
Whereas for NES and N64, I don't know any reason it would not be enough.
DiscoRico wrote:
Also, what is autopolling?
Autopolling is SNES hardware feature where the system itself once per frame polls the controllers and writes the result to special registers, saving the game from having to poll the controllers itself (it can just then read those special registers).
The reason it is relevant: Autopolling causes controllers to be polled regardless of lag, whereas without it, games often just don't poll on lag, yielding implicit "skip lag" function.
DiscoRico wrote:
4 more bits for SNES adds LT, RT, X, and Y. Does this mean that NES and SNES both use some form of PWM or PPM to deliver button input?
Actually, A, X, L and R (in that order). The B and Y would correspond to NES A and B.
The NES and SNES use the following protocol:
1) Console pulls latch high.
2) Controller latches the controls into shift register.
3) Console pulls latch low.
4) Console reads B (for SNES, A in case of NES) from data line.
5) Console pulls clock high.
6) Controller shifts the shift register by one position.
7) Console pulls clock low.
8) Console reads Y (for SNES, B in case of NES) from data line.
... Repeat steps 5-8 until all bits are read.
DiscoRico wrote:
I see. How does it aid in exporting data?
Using it, one can extract the button data that lacks those frames that are never polled (and duplicated if polled twice).
This form is much easier to work with when doing a bot: One can just latch the next record when latch signal is detected and not have to think about timing.
So just to make sure this is feasible, SNES games in which UP+DOWN and LEFT+RIGHT are allowed are viable input?
Would a SNES bot be more reliable in terms of syncing if a SNES controller were disassembled and the mechanical switches for each button were replaced with signals from an Arduino corresponding to each button input?
EDIT:
After reading Ilari's fabulous post, I believe I understand phenomenally more. Is input on the controller stored into a shift register as well, and then sent on the data line as pulses? Then those data line pulses are read and stored in a shift register on the console itself?
So just to make sure this is feasible, SNES games in which UP+DOWN and LEFT+RIGHT are allowed are viable input?
Would a SNES bot be more reliable in terms of syncing if a SNES controller were disassembled and the mechanical switches for each button were replaced with signals from an Arduino corresponding to each button input?
U+D/L+R is entirely possible from an electrical standpoint. It's a mechanical lockout on some controllers that can prevent it, depending on how hard you press.
I don't think gutting a SNES controller is useful. The only electronics in it are a simple shift register which is very well understood.
So just to make sure this is feasible, SNES games in which UP+DOWN and LEFT+RIGHT are allowed are viable input?
I don't know of any electric-level protections against LEFT+RIGHT or UP+DOWN. The only protection seems to be mechanical.
DiscoRico wrote:
Would a SNES bot be more reliable in terms of syncing if a SNES controller were disassembled and the mechanical switches for each button were replaced with signals from an Arduino corresponding to each button input?
Nope, the bot would just need to react properly to latch and clock and control the data line (BTW: if bsnes source is any indication, the data line has 4 states (I don't know if it is 4-ary or 2 binary lines)).
Edit: It is apparently 2 binary lines (pins 4 and 5 in the connector). If one is dealing with simple gamepad, pin 5 can be left unconnected.
TASes are recordings of input from power-on correct? In that case, could a signal be wired from the SNES power switch to circuitry that would automatically deliver the first input at (as close as possible) the same time as the emulated version?
In other words, have the microcontroller in a sleep-state, or Wait-For-Interrupt, and have the power-on signal start playback?
TASes are recordings of input from power-on correct? In that case, could a signal be wired from the SNES power switch to circuitry that would automatically deliver the first input at (as close as possible) the same time as the emulated version?
You don't need to do that. Just wait for the console to assert latch and then latch the first input.
That is, if console asserts latch, load next word (the first word on the first latch) and output its first bit on data line. If console asserts clock, switch to next bit of the current word to be output on the data line.
Brilliant. Is there any good website that has a repository of this information so I can quit bugging you all? I've tried taking a look at how the controller and whatnot function and you've all been so kind as to explain that much to me.
One quick question:
Am I correct in understanding that the data signal is the only signal that originates at the controller, while the clock and latch lines originate at the console?
Joined: 6/2/2009
Posts: 1182
Location: Teresópolis - Rio de Janeiro - Brazil
I know nothing of programming, but some time ago I connected a NES controller on a SNES (with some cutting and soldering), and it worked. Is it possible to adapt what already exists to verify NES games to work on SNES games too? It may be too bizarre, sorry to bother you guys.
I am old enough to know better, but not enough to do it.
Yes. The problem is that bsnes and friends is the only emulator worth testing, and there aren't many runs for it yet. Also, the current NESbot is a bit problematical in some ways.
Is it possible to adapt what already exists to verify NES games to work on SNES games too?
The onboard shift register would have to be expanded from 8 to 16 bits (and software modified to be able to use that). Other than that, it is just the connector.
AFAIK, someone has already done a version that works with SNES (but as said, there are very few games to really try it on).
