SNESoIP: SNES Ethernet Adapter

[mupfelofen-de]

SNESoIP ist ein (Work in progress) Ethernet Adapter für das Super Nintendo basierend auf einem megaAVR und dem ENC28J60 Ethernet-Controller. Der Adapter selbst verändert keine Spielinhalte (wie z.B. das XBAND-Modul), sondern tauscht lediglich die Controller-Eingaben über einen gemeinsamen Server.

Status (zuletzt aktualisiert am 29.08.2013):
Das Projekt befindet sich im Entwicklungsstatus. Tests stehen noch aus.

Hardware: Einseitiges SMD-Layout auf selbst fabrizierter Leiterplatte.
Firmware: Netzwerkfunktionalität vollständig implementiert. Aktuell belegter Flash-Speicher des verwendeten µCs (ATmega8): 6876 von 8192 Bytes.
Unix-Server: Die Kern-Funktionalität ist voll implementiert.

Die nächsten Schritte:

• - Aufbau der ersten beiden Prototypen. (50% fertig)

Feature-Requests sind ausdrücklich erwünscht und zu jeder Zeit herzlich willkommen!

---
Hi zusammen,
erstmal sorry, dass ich hierfür extra einen neuen Thread eröffne, da es A. bereits einen vergleichbaren Beitrag von lytron gibt und B. mein eigener Beitrag in eine ähnliche Richtung schwenkt.

Ich habe jedoch eine konkrete Idee, für deren Umsetzung mir jedoch noch einige Informationen und Ideen fehlen.

Und zwar würde ich gerne einen Adapter entwickeln, der die eigene Controller-Eingabe an einen zentralen Server schickt und die Controller-Eingabe für den jeweils anderen Controller-Port vom Server liest und beide Eingaben an das SNES weitergibt. Jeder dieser Adapter könnte, so mein Gedanke, über eine einmalige ID verfügen, die sich auf dem Server meldet. An jedem Adapter könnte man dann z.B. via DIP-Schalter die ID des Host-Controllers angeben.

Meldet man sich dann auf dem Server an, so registriert der Server A. die eigene Anwesenheit und B. überprüft er die Anwesenheit des eingestellten Hosts. Ist dieser online, so könnte man das z.B. via LED bestätigen.

So viel zur Hardware. Auf diesem Wege könnte man, wohlgemerkt recht preisgünstig, die Controller-Eingaben über das Internet schicken.

Nun zum problematischen Teil: der Software.

Mir ist bewusst, dass die meisten Spiele mit Pseudozufallszahlen-Generatoren arbeiten und ein absolut identisches Spielverhalten, welches für die oben beschriebene Idee nötig wäre, beinahe ausgeschlossen ist. Meines Wissens wurde dieses Problem von XBAND-Modul mit Rom-Patches gelöst, die direkt über das Modul von einem zentralen Server heruntergeladen wurden. Weiß hier jemand genaueres?

Falls diese Patches lediglich die Pseudozufallszahlen-Generatoren außer Kraft gesetzt haben, so könnte man dies doch mit einem entsprechenden Rom-Hack lösen, oder nicht? Falls ja, kennt sich da jemand aus und wie groß wäre der Aufwand dafür?

Ansonsten würde ich mich einfach über ein paar Ideen und Denkanstöße freuen, um aus diesen Gedanken vielleicht tatsächlich funktionerende Hard- und Software zu zaubern.

PS: Hätte hier jemand (ernsthaftes) Interesse an einer solchen Hardware? Ich würde mich A.) über Hilfe mit der Software freuen und B.) wäre das irgendwie witzlos mit nur einem Super Nintendo (wobei man das mit Sicherheit auch auf einem Emulator implementieren könnte ).

[lytron]

Schöne Sache, mupfelofen!

Was ich alles dazu schreiben wollen würde, sprengt ein wenig den Rahmen... und gerade meinen Kopf. Trotzdem, ich wäre gespannt zu sehen, wenn du soetwas zu stande bekämest.

Der erste Schritt wäre, dass man ein Hardware-Dingens hinbekäme, das in der Lage ist, den SNES-RAM überhaupt auszulesen. Ich glaube, wenn man soweit ist, kann man sich über die Software-Lösungen Gedanken machen.

Wie lange es dauert, ein Spiel entsprechend zu hacken, kann ich dir nicht sagen (ich bin kein Hacker). Ein Spiel komplett zu disassemblen würde ich mal ab 500 Arbeitsstunden aufwärts ansetzen, wobei es wesentlich schneller geht, sobald man in der Übung ist.

[mupfelofen-de]

Der erste Schritt wäre, dass man ein Hardware-Dingens hinbekäme, das in der Lage ist, den SNES-RAM überhaupt auszulesen. Ich glaube, wenn man soweit ist, kann man sich über die Software-Lösungen Gedanken machen.

Ich glaube, ich habe etwas für Verwirrung gesorgt als ich von einem Adapter gesprochen habe, da ich nicht an einen Adapter gedacht habe, der sich zwischen das SNES und die Cartridge klemmt. Die gesamte Kommunikation zum SNES soll ganz gewöhnlich über die Controller-Ports funktionieren.

Stell dir einfach einen Adapter mit einem Controller-Eingang und zwei Ausgängen vor. Alles was über den Eingang an Daten reinkommt, wird an einen der Ausgänge weitergereicht und gleichzeitig zum Server geschickt. Der zweite Ausgang bekommt die entsprechenden Daten vom Server.

Die Ausgänge müssten dann natürlich beim Mit- oder Gegenspieler über Kreuz in das SNES gesteckt werden.

Darum eben meine Frage, ob ein Rom-Hack reicht um ein vollständig gleiches Spielverhalten zu erreichen. Also keine Live-Synchronisation der Spiele, sondern vielmehr ein Vertrauen auf die Gleichheit des Spielverhaltens.

Zum Hardware-Design habe ich mir schon einige Gedanken gemacht (und auch schon ein paar Komponenten bestellt) und wird vermutlich kein allzu großes Problem darstellen.

[lytron]

Ach so, ein Anschluss für den Controller-Port. Interessante Vorstellung...

In Realität könnte ich mir trotzdem vorstellen, das es da zu viele Probleme gibt. Denn, unabhängig vom Zufallszahlen-Schingeling, muss die Datenübertragung nur so lange hapern, dass meine Controller-Daten einen Frame zu spät auf deinem SNES ankommt, dass damit dann alles Käse ist. Ich weiß nicht, ob das bei "normalem" Betrieb auftreten könnte, ich vermute mal, dass die Internetleitungen mittlerweile schnell genug sind (obwohl ich nicht vom Fach bin)... aber dann muss nur mal das Internet laggen...

... wie auch immer. Ich denke, bevor man sich Gedanken über solche Hacks macht, sollte die Technik erstmal da sein.

Wenn sie da ist, bin ich gern der Erste, der dir eine Test-ROM schreibt!

[mupfelofen-de]

In Realität könnte ich mir trotzdem vorstellen, das es da zu viele Probleme gibt. Denn, unabhängig vom Zufallszahlen-Schingeling, muss die Datenübertragung nur so lange hapern, dass meine Controller-Daten einen Frame zu spät auf deinem SNES ankommt, dass damit dann alles Käse ist. Ich weiß nicht, ob das bei "normalem" Betrieb auftreten könnte, ich vermute mal, dass die Internetleitungen mittlerweile schnell genug sind (obwohl ich nicht vom Fach bin)... aber dann muss nur mal das Internet laggen...

Die zu übertragendene Datenmenge ist vernachlässigbar. Am SNES werden 16-Bits eingelesen, wovon nur 12 tatsächlich gesetzt werden. Und selbst in der XBAND-Era konnte man die Daten mit 2.400 Bit pro Sekunde übertragen. Ich denke, würde das nicht funktionieren, hätte es damals auch nicht beim XBAND geklappt, dass hauptsächlich Controller-Daten übermittelt hat. Aber bin ebenfalls nicht vom Fach und vielleicht vergesse ich einfach nur einen anderen wichtigen Faktor.

... wie auch immer. Ich denke, bevor man sich Gedanken über solche Hacks macht, sollte die Technik erstmal da sein.

Gerade kam der erste Lionsware SNES-Controller zum Ausschlachten mit der Post. Werde mich also ranhalten. Einen Händler für SNES-Controller-Buchsen habe ich auch schon gefunden. Ich schätze, die Umkosten für den gesamten Adapter werden bei etwa 25€ liegen. Fortschritte poste ich gerne hier.

Wenn sie da ist, bin ich gern der Erste, der dir eine Test-ROM schreibt!

Jipii, eine Sorge weniger.

[lytron]

... wie auch immer. Ich denke, bevor man sich Gedanken über solche Hacks macht, sollte die Technik erstmal da sein.

Gerade kam der erste Lionsware SNES-Controller zum Ausschlachten mit der Post. Werde mich also ranhalten. Einen Händler für SNES-Controller-Buchsen habe ich auch schon gefunden. Ich schätze, die Umkosten für den gesamten Adapter werden bei etwa 25€ liegen. Fortschritte poste ich gerne hier.

Gerne.
Klingt ja fast, als würdest du sofort anfangen.

Wenn sie da ist, bin ich gern der Erste, der dir eine Test-ROM schreibt!

Jipii, eine Sorge weniger.

Joa, die ROM würde dann für jeden Controller den Frame und die Scanline-Position des letzten Button-Pushs ausgeben (folglich stünden dann sechs Werte auf dem Screen: Frame, Scanline (y-Koordinate) und Scanline-Position (x-Koordinate).
Wenn du das dann testen würdest, wäre der (unerreichbare) Idealfall, dass auf beiden Fernsehern dieselbe Zahl steht. Ich (ohne technische Kenntnis, wohlgemerkt) erwarte, dass es eine Differenz von maximal einem halben Dutzend Scanlines gäbe, was auch schon kritisch wäre (je größer die Differenz, desto wahrscheinlicher, dass die Controller-Daten nicht mehr im selben Frame ankommen, wie sie abgeschickt werden).
Wenn die Differenz höher als ein Frame ist... na ja, wäre deine Zeit sinnvoller in Wagen Waschen investiert.

[mupfelofen-de]

Gerne.
Klingt ja fast, als würdest du sofort anfangen.

Genaugenommen habe ich das bereits.

[lytron]

Kleine Korrektur, mein Fehler, fällt mir gerade erst ein:

Die ROM braucht nur den Frame zu enthalten. Weil: Es ist egal, wann das Ding gedrückt wird, die Daten aus dem Port werden eh nur einmal pro Frame abgefragt. Folglich geht es dann nur um den Frame, quasi hopp-oder-topp.

Falls das dann nichts wird... könntest du ja einen Adapter zum "Dazwischenstecken" (zwischen Controller und SNES) basteln, der die Daten an zwei weitere Anschlüsse weiterleitet. Dann könnte man wenigstens einen SoM-Dreispieler-Hack machen, bei dem die drei Figuren nicht alle im selben Screen sein müssen.

(wenn auch Sie im selben Raum bleiben müssen)

Gerne.
Klingt ja fast, als würdest du sofort anfangen.

Genaugenommen habe ich das bereits.

Hell yeah.

[ChronoMoogle]

Sehr cooles Projekt, ich beobachte gespannt!

(wenn auch Sie im selben Raum bleiben müssen)

Das koennte man vll mit einem Hack fixen, der nur Player 1 erlaubt, die Teleporttiles zu betreten.

[lytron]

Das koennte man vll mit einem Hack fixen, der nur Player 1 erlaubt, die Teleporttiles zu betreten.

Aber wie soll ich dann meinem Bruder auf den Sack gehen?

Hm. Ein SoM-Hack wäre wegen des Zufallszahlen-Dingens ein bisschen kompliziert, fällt mir ein.
Hm. Hm, hm, hm. Je länger ich drüber nachdenke, desto döfer ist das eigentlich, auf diese Weise einen Multiplayer zu machen. Das wäre softwareseitig mit so vielen Workarounds und/oder banges Hoffen auf 100%iges Synchronlaufen verbunden... all das könnte man mit einer XBand-Cartridge oder gleichwertigem wesentlich leichter bewerkstelligen. Denn da könnte man viele Dinge mit dem Abgleich einzelner Bytes sicherstellen etc.

[mupfelofen-de]

all das könnte man mit einer XBand-Cartridge oder gleichwertigem wesentlich leichter bewerkstelligen. Denn da könnte man viele Dinge mit dem Abgleich einzelner Bytes sicherstellen etc.

Hat das XBAND-Modul das tatsächlich gemacht?
Nachdem was ich bisher darüber gelesen habe, hatte ich den Eindruck, dass ebenfalls nur statische Patches eingespielt wurden.

[lytron]

Ohne Garantie und aus dem Gedächtnis:

Das Xband patcht unterstützte Spiele (d.h. jeweiliges im oberen Slot eingestecktes Originalmodul) live, die Patches werden auf dem internen SRAM gespeichert (mein Modem hatte IIRC noch den Mario Kart Patch drauf).
Während des Spiels werden primär Controllereingaben ausgetauscht.
Das Xband versucht, die beiden verbundenen Konsolen Frame-genau zu synchronisieren und synchron zu halten, das heisst, das Spiel läuft im Idealfall auf beiden Konsolen exakt identisch.
Dazu gehören auch die Pseudozufallsgeneratoren des Spiels.

Ich habe da auch nicht mehr Informationen als du, ich werde mal meinen Kumpel heute abend fragen, der ein paar Orte weiter wohnt, vielleicht weiß der was.

Ansonsten, falls das wirklich "statisch" mit den Patches ist (was ich nicht glaube, zumal d4s oben von "live patchen" redet), fällt das dann bei "X-Band oder gleichwertig" unter die Kategorie "oder gleichwertig".

[mupfelofen-de]

Ich habe angefangen einen mininalistischen Server (und Client) zu schreiben. Der Server speichert 2 16-Bit Variablen mit den Controller-Eingaben. Da der SNES-Controller jedoch lediglich 12-Bit benötigt um alle möglichen Kombinationen darzustellen, verwende ich die übrigen 4-Bit quasi als Information für den Server ob der Client A.) eine Variable ändern oder abrufen möchte und B.) welche Variable er anpeilen soll.

So werden bei jedem Datenaustausch lediglich 16-Bit übertragen.

Hatte leider nur wenig Zeit dafür, möchte das am Wochenende aber fertig haben.
Das ist nicht viel, aber für einen ersten Test reicht es allemal.

We'll see.

[lytron]

Öhm. Die verbliebenen vier Bit sind nicht nutzlos. Du solltest sie auch checken, da sie die Angabe enthalten, was angeschlossen ist (0000 = Controller, 0001 = Maus (glaube ich), usw.). Außerdem können, wie z. B. bei der Maus, auch mal 32 Bit an Daten kommen.

Nichts desto weniger: Chice Sache, mach weiter so.

EDIT: Und bei der erstbesten Gelegentheit... FOTOS! FOTOS! FOTOS!

[mupfelofen-de]

Öhm. Die verbliebenen vier Bit sind nicht nutzlos. Du solltest sie auch checken, da sie die Angabe enthalten, was angeschlossen ist (0000 = Controller, 0001 = Maus (glaube ich), usw.).

Ich weiß, aber was ich meinte betrifft einzig und allein die Kommunikation zwischen dem Client und dem Server. Auf diese Weise schick ich (für den Anfang) immer gleich große Datenpakete hin und her, die nur das nötigste beinhalteten um zumindest die Controller-Eingaben hin- und herzutauschen. Da kommen mir die übrigen 4-Bit gerade recht.

EDIT: Und bei der erstbesten Gelegentheit... FOTOS! FOTOS! FOTOS!

Klar, sobald es an die Hardware geht. Aber eins nach dem anderen. Sobald der Server funktioniert, möchte ich erstmal versuchen den Controller auszulesen und die Eingaben zu simulieren, bevor es an die Netzwerk-Geschichte geht. Freu mich schon drauf!