How to create a dual output NES controller?

Hi there,

I have recently been attempting to create a dual output nes controller so that I can hook up & compare 2 consoles with 1 to 1 input using the same game.

So far I have tried to hook 2 output cables to the leads on a single board and it makes one of the NES' screens turn purple or not turn on at all.

After that I attempted to stack 2 boards, each using their own output leads, then attach their ground lead together + run a wire from each button to the other board's button. This works for a while but when I hook this up to both the AVS an original NES the original NES throws random inputs + pauses after a few seconds of holding down a single button.

Any ideas on how to get this to work reliably would be great.

Note: I used 2 Tomee NES Controllers for this project since I didn't want to ruin any original hardware while testing.

V/r,
Eatitup86

Splitting leads is no good. The NES drives the controller, not vice versa - the two clock pins will conflict there, and they'll only ever get garbage data back to the consoles if at all.

You need the two controller PCBs to perform their parallel loads off of the same buttons, but independently shift the data back to each NES. Two controller ICs must be used.

This has been done at the latest SGDQ, for 4 consoles, one of which was FDS. They played back a single input file on all of them.

http://tasvideos.org/forum/viewtopic.php?t=18136
https://www.youtube.com/watch?v=cPunu3q36Xk

This seems like the start of the correct approach, but there's probably a few additional factors to reckon with, e.g. don't you need to keep the two consoles' power supplies isolated?

This is true, I forgot to mention this. Only one console should be powering the controller boards; the 5V rails should not be connected.

I attempted to only hook up one 5V to both and it would not work. When both are separated into their own boards though shouldn't they function independently? The only thing connecting the two is the ground and the buttons with my current setup. Does every button need to be independently grounded for a total of 16 wires? Currently I had 8 for the buttons + 1 for ground.

Quick update + photos. I tried to link the voltage point on both by disconnecting one and running a wire to the other. It sorta works. When I press up or down the AVS adds right to it and pressing right adds down while left seems to work fine. During all that the nes functions normally. Also other buttons work fine on the AVS so it just seems to be those 3 directions. Any ideas?

I put some photos of it up on Google drive here:
https://drive.google.com/folderview?id= ... mpGbC0xOTA

Could this have something to do with the pull down resistor in the US NES? Maybe I need to do something to copy that on the connected board or something?

Even if you succeed with this, and even if both consoles behave identically, couldn't you still have problems sync'ing the gameplay between them? Both consoles will be running at 60 fps (or 50, if PAL), but that doesn't mean that frames start and end at the same time on both consoles, there's no guarantee that they'll be perfectly aligned like that. Thus, if you're running a game that reads the controller at the beginning of the frame, it's possible that you'll release or press a button after the first console has read the controller but before the second one does it, resulting in different logic running on each console.

With this in mind, I don't think that connecting one controller to multiple consoles simultaneously is a great way to test the accuracy of a console. If what I wrote above is correct, even 2 authentic NES's would produce slightly different results.

Plus 60 Hz for anything HD != 60.0988 Hz that the NES generates.

I don't know why you keep reinventing the wheel, dealing with problems that have already been solved, as proven by the source code of the project I linked.

So the AVG will actually run at a slightly different speed from the NES? I can totally see that screwing things up over time.

If the consoles did run at the same speed, maybe you'd be able to sync the input if you built some kind of buffer between the controller and the consoles, which would hold the same button states for the exact duration of a frame, guaranteeing that both consoles would catch the same input state for the same logic frame. Lag frames might screw this up though.

I'm assuming so, seeing as its competitor (Kev's Hi-Def NES and the latest Analogue Nt) slows down the CPU and PPU slightly to conform with HDMI frame timing.

I also know of an easy way to verify it. There's a stopwatch function in my NES port of the 240p Test Suite that assumes 3600 frames per minute, compared to the actual hardware's 3606. Run that for an hour on an unmodified NES, Hi-Def NES, and AVS side by side. The NES should be 6 seconds ahead at the end.

In the TASbot video feos linked the consoles are playing separate streams, and they do get out of synch by the end (mentioned by the commentator). It's the same input data, but being fed to each machine independently rather than trying to do them all with the same signal.

Yes, consoles getting out of sync, even if you launch them at the same time, is the main reason it's not done the way OP is trying to do it. At first we were talking about several tasbot devices, one for each console, then micro500 came up with this new thing that alone feeds the data at the same rate the console asks for it, for each console you connect to it. So yes, it's the console that drives the process, not the controller.

That all is pretty interesting.

I didn't try the TASBot solution because I already have the parts here to attempt the controller setup and I am not sure I have enough knowledge to build one.

I did not know the hz were actually different between the consoles and that actually is kinda surprising given it is supposed to be as close as possible to the real NES.

How would something like this effect speed run times? Would it even be allowed for an official time? Do emulators have this hz rate taken into account?

I mainly wanted to get this working to show a twitch stream of the two side by side but that delay is concerning. :\

That being said I would love to see something like that side by side of a nes vs the AVS vs the Hi-Def NES & other alternatives.

If nothing else comes of this I will say that if you hook both ends of this solution into an AVS or NES as player 1 & 2 it does work properly for 2 player 1 controller which is kinda neat.

60.1 Hz vs 60.0 Hz makes a bit less than 0.2% difference, or roughly speaking it adds 1 second per 10 minutes. (Real NES is the faster one.)

Some emulators do take it into account, some don't, the best ones have options.


If you record both at their output framerates, you could rescale them to show them side by side- they should match frame for frame if you used a poll-based input stream like TASbot does.

It's not possible to rescale them live, of course. Otherwise you can use short demonstrations to keep them closer to synchronized.

At least the 0.165% speed difference isn't nearly as bad as that between a Game Boy and the original Super Game Boy. The Game Boy runs at 4.194 MHz, while the Super Game Boy divides the Super NES's 945/44 MHz master clock by 5 to produce a 4.295 MHz clock. This is (945/44/5*1000000/2^22-1)*100 = 2.4% faster than standard. The Japan-only SGB2 runs the Game Boy on a separate 20.97 MHz crystal for correct speed and sync over the link port, which was left off the original SGB.

For speedruns a scaling factor could be applied to the times to make them comparable, as long as one doesn't get stuck on the fact that the marginally (really, really marginally) lower frame rate could make the game easier to play.

Best way to measure times for speedruns would be to do the measurements in frames (number of output frames from the system), although that is often not practical.

Even when a game has a built-in timer, which is usually a frame-based counter, speedrunners seem to prefer it to be measured with an external clock in most cases. (Don't ask me why. Maybe to do with pausing, etc. often not counting on the game timer.)

Yep pausing stops a lot of in game timers.

I would think it would be possible to capture the total frames with an update to a device like the AVS though wouldn't it?

That would be a really neat feature. It already does have a timer that kicks of right when you start a game but does not really use it for anything I am aware of at this time. It simply uses game scores for it's scoreboard app from what I have observed using it for the few days I have had it.