Hardware Synchronization Ideas

---

HARDWARE RESET AND FINDING OPPONENTS

---

On powerup of the SNESoIP while the light is red, users can hold a combination of buttons to indicate which game they are using. For instance, Super Mario Kart could be X+R on the joypad. Many different button combinations can be used and i highly doubt that the amount of games that exist for the snes that will work perfectly via the SNESoIP without random issues will exceed the combinations of buttons that can be made.

When the SNESoIP detects this it can store it for later use when searching for an opponent. Once we are connected to the server and the led light is green, we can then send out a packet of data to the server indicating we are looking for a person playing the game we held the buttons down for when we powered up the SNESoIP.

Once we find another user sending out the same request we can then send a few packets back and fourth to determine the latency between both users (average latency) and then issue the command to do a synchronized hardware reset. This will trigger an output on a pin of the ATMEGA8 which will ground the reset line on the SNES console EXT port for about 2-3 seconds or so and then let the console start.

The RESET pin will be the 5TH pin from the left on the ext port if you are looking at the console with the front of the console facing down and the controller ports facing tword you. Once ground is RELEASED from this pin, we immediately then jump start into the Game synchronization method described below.

---

GAME SYNC

---

Every 16.67ms (or about 60Hz), the SNES CPU sends out a 12us wide, positive going data latch pulse on PIN 3 of the controller port. Six microseconds after the fall of the data latch pulse, the CPU sends out 16 data clock pulses on pin 2.

With this in mind, the latch signal on pin 3 can be used to trigger code that will increment a variable called 'SYNCPULSE' by 1. Once this variable >= 60 (or whatever we set it to) it will reset back to zero. The SYNCPULSE LIMIT could be calculated based on the latency to the other player based on ping packets.

We can then use the empty remaining 4 bytes within the UDP data packet which is holding the controller data to send out the current SYNCPULSE we are on currently to the other SNESoIP device we are linked with.

Once this UDP packet is received on the other SNESoIP, the additional data for the sync pulse is inspected. Based on its OWN SYNCPULSE and the received one in the data packet, if it is running faster it will slow itself down via the method described further below. After the data is analyzed, syncpulse data bits are REMOVED from the data packet prior to sending this controller data packet on to the SNES controller ports.

The method used to slow down Each system can be done via switching from 60hz to 50hz briefly.. this will slow everything overall instead of pausing the cpu with the HALT pin which COULD causing stuttering gameplay and sound, and maybe crashing. The halt pin is un-tested however...

Both consoles would need to have the modification for a 50/60hz switch and the SNESoIP would default BOTH consoles to 60hz by default so it would have the ability to slow down the faster console.

We would need an additional 2, possibly 3 I/O lines to fed into the ATMEGA8 on the SNESoIP to trigger this 50/60HZ function and reset line. Currently at a quick glance it looks like we have the following I/O Lines free...

ADC6,ADC7,PC5,PD3,PD4,PB0,PB1

50/60HZ Mod information can be found HERE

THE BAD

This method can work quite well, however it does require soldering of a 50/60hz mod wires. Also, WHILE the sync process is happening (if out of sync) you may see the screen flicker or swap between pal/ntsc screen resolution. The difference would be the slightly smaller picture with borders vs the ntsc version which is full screen. This can be annoying. This can be seen HERE in this youtube video.