nesdev.org

Hello everybody,
this is my first post on this board, so let me say hello! I'm an hobby engineer and SNES enthusiast from Stuttgart, Germany and after 4 weeks of work I want to present you my current project: the SNESoIP.

The SNESoIP ethernet adapter for the Super Nintendo/Famicom will be an open-source, proof-of-concept, network-bridge for sharing local controller-inputs over the Internet.

The project it currently in its early stage, but fully functional and could be used to play multiplayer games over the Internet. Also some kind of server-controlled BBS system could be conceivable as a future project.

Images
2013-08-28-prototype-01.jpg
2013-08-28-prototype-02.jpg
2013-08-28-prototype-03.jpg

Features

• - Plug and play (IP is obtained via DHCP),
  - DNS lookup of the server hostname,
  - small firmware size (fits on an ATmega8),
  - easy to rebuild (even on a stripboard),
  - low component count,
  - adaption of other platforms (e.g. Sega Mega Drive) is possible
  - possible cross-platform capability.

Todo

• - Some kind of interface to avoid hard-coded configuration,
  - detailed documentation.

How it works
Communication
The SNESoIP ethernet adapter is continously sending 4-byte data packets via UDP to a (remote) server and may receive 2-byte answer packets from the (remote) server.

A packet sent to the server has the following format:

• Byte 1: Controller Data Lo-Byte
  Byte 2: Controller Data Hi-Byte
  Byte 3: CID
  Byte 4: P2CID

An answer packet has the following format:

• Byte 1: Controller Data Lo-Byte
  Byte 2: Controller Data Hi-Byte

The 2-byte Controller Data field holds the state of SNES controller which is basically a 16 bit shift register of which 12 bits are being used to represent button states (unused bits are pulled high).

CID is a value uniqely identifying the sending controller instance to the server and used to store its state on the server.

P2CID is the CID of your selected "Player Two". The server will answer your packet with the controller data of the controller identified by P2CID.

Update packets are being sent to the server continously even if the local controller state does not change state.

Switch Mode
To ease sorting out which player is to play as player 1 and which is to play as player 2 and prevent tedious interchanging of plugs the SNESoIP implements a "Switched mode" which exchanges player 1 and 2 in software.

To activate "Switched mode" simply hold down the B and Y keys of your controller while booting the SNESoIP. If successful, the SNESoIP's LED will blink briefly.

To deactivate "Switch Mode", simply reboot the SNESoIP without any buttons held down.

As I said, the project is currently in an early stage and will be released under the terms of a BSD-like license after it passes the current testing-phase. Till then feel free to discuss or ask me any questions related to this topic.

Greetings
Michael

PS: The original topic can be found at snesfreaks.com (german).

Google translation of discussion

I take it you plan on having two SNES consoles linked over IP, with both running the same game and two people playing a two-player game. If so, how will the two SNES consoles stay in sync?

blargg wrote:Google translation of discussion

I take it you plan on having two SNES consoles linked over IP, with both running the same game and two people playing a two-player game. If so, how will the two SNES consoles stay in sync?

That's right but to be honest, I ignore synchronization issues, random events and possible network latency, because I can not say anything about it without further testing. The second prototype is currently on its way to a beta tester, so I've to wait a few days.

Anyways, this is just one possible application. I'm currently thinking about some kind of BBS or server-controlled online game where the SNESoIP can download information at any time. Synchronization should not affect that.

PS: Please be indulgent; english is not my native language.

X-Band required games to be hacked/patched to eliminate random behaviors because it functioned in a similar way where controller data was exchanged, and probably some pre&post game communications. This can work, but it's critical not to let anything possibly desync the two consoles and their game states.

Likewise, games supporting GGPO delay the local effect of controller presses by about three to four frames (just over half a ping) so that they arrive on time on average, and the engine has to be able to rewind to a saved state and catch up should they fall out of sync due to unexpected lag.

This is awesome! Keep us posted on your development of this concept; it could become huge in the retro gaming community!

Good luck with your project.

Thank you guys.

PS: The second prototype has just arrived and i will probably start testing later this day. If it work as expected, I will upload the project files to GitHub.

http://www.youtube.com/watch?v=8fhYhGJ80Dg

Random events fucked it up, but at least we did it!

Nice job, even despite the sync issues.

The tester accidently played in 60hz mode. Now we successfully played through the first two levels of Zombies ate my neighbours.
We also did some measurement with a custom ROM: we get an delay of 2-4 frames but after a few inputs, everything is in sync again. Success!

Cool project, although I can't say your videos are meaningful at all.

Edit: Stuttgart? That's where I was born.

I'm assuming the running into corners is an attempt to have both games in sync?

That was my assumption, or that it was inadvertent and ending up acting as a limit on how out-of-sync they could get. It'd probably be fun to see a video of both NES screens at once.