snesfreaks.com

Ist alles etwas lange her bei mir ... grad nochmal in der Gedankenkiste gewühlt ... den HexBuffer braucht man nicht wirklich. Hatte ihn anfangs verwendet. Kannst dich vielleicht an der Riegel-Lib orientieren ( http://www.roland-riegel.de/sd-reader/ ). Für reinen Lesezugriff reicht ein ATmega8, ATmega168 für read/write (alles für FAT16). ATmega328 für FAT32. Ich weiß jetzt nicht, was du an Platz brauchst. Es gibt bestimmt noch andere, vielleicht auch schlankere Libs.

Hello, SNESoIP!

Oh, klasse! Glaub ich jedenfalls. Mangels Fachkenntnissen. Aber generell ist das doch ein gutes Zeichen, oder?

Christian hat geschrieben:Oh, klasse! Glaub ich jedenfalls. Mangels Fachkenntnissen. Aber generell ist das doch ein gutes Zeichen, oder?

Ja und nein.
Es ist zwar überhaupt kein Problem Server-Applikationen für den Mikrocontroller zu schreiben, aber ihn als Client zu verwenden, gestaltet sich offenbar schon schwieriger. Jetzt heißt es erst einmal recherchieren.

Aber wenigstens funktioniert inzwischen DHCP (automatische IP-Zuweisung z.B. über einen Router).

Update: erste Erfolge via UDP. Video folgt.

würd dir auch zu udp raten, man kriegt zwar keinen timeout aber ist dafür nicht so anfällig.

F_L_a_S_H hat geschrieben:würd dir eh zu udp raten, man kriegt zwar keinen timeout aber ist dafür nicht so anfällig.

Ja, aber leider hat man keinerlei Sicherheit ob alle Daten übertragen wurden (was bei dieser Anwendung vermutlich keine allzu große Relevanz hat).

Wie meinst du das mit nicht so anfällig?
Hab mich bisher leider nur sehr oberflächlich mit TCP und UDP auseinandergesetzt.

Hier das Video:

https://vimeo.com/72150527

du musst halt bei tcp richtig Verbindungen aufbauen, auf neue warten usw
das ist bei udp bisschen leichter, vor allem weil du ja so fifo mäßig arbeitest

Bei TCP wird auch darauf geachtet das die Daten ordentlich ankommen.
Du also zusätzlich zu den eigentlichen Daten noch den "overhead" der Paritäten.

Bei UDP nimmst du einfach das an was kommt ohne zu prüfen ob es das ist was dir eigentlich zugesendet werden sollte.

Edit:
Habe grad nochmal nachgelesen: Das bilden einer Prüfsumme kann man auch bei UDP machen. Das war mir neu...

Btw:
Sehr cooles Projekt. Auch wenn ich zur Zeit noch ein wenig an der Sinnhaftigkeit zweifle ^^'
Stellst du den Source eigentlich zur Verfügung? Mir wäre so als hätte ich dazu mal was gelesen aber ich finde es nicht mehr oÔ

Normalerweise wird im Spielebereich meistens UDP benutzt aufgrund des erwähnten Overheads bei TCP. Die Frage ist natürlich in wie weit der Overhead bei dieser geringen Datenmenge ins Gewicht fällt und ob es wirklich wichtig ist, dass alle Pakete ankommen. Das lässt sich sicher nur durch Tests feststellen.
Ich finde das Projekt auch extrem interessante und freue mich immer, wenn es hier einen neuen Beitrag gibt. Weiter so!

Farbauti hat geschrieben:Bei TCP wird auch darauf geachtet das die Daten ordentlich ankommen. […]
Bei UDP nimmst du einfach das an was kommt ohne zu prüfen ob es das ist was dir eigentlich zugesendet werden sollte.

Ist in dieser Anwedung ja eigentlich auch egal ob die Daten ankommen oder ob sie gelegentlich falsch übertragen werden. Im Bruchteil einer Sekunde werden die (i.d.R.) korrekten Daten ja noch einmal übermittelt. Und wirklich sensibel sind die Daten ja auch nicht.

Farbauti hat geschrieben: Habe grad nochmal nachgelesen: Das bilden einer Prüfsumme kann man auch bei UDP machen. Das war mir neu...

Da es das erste Mal ist, dass ich mich überhaupt mit Socket-Programmierung und dem Programmieren von Internet-Anwendungen auseinandersetze, habe ich auch erst beim Stöbern im Netz darüber gelesen. Aber eine echte Prüfsumme wie z.B. CRC-16 wäre wahrscheinlich unnötig. Ich mein, ich übertrage gerade mal 2 Byte Controller-Daten und weitere 1 bis 2 Byte um den Server herumzukommandieren.
Sollte es hier wirklich zu Problemen oder unkontrolliertem Verhalten im Spielbetrieb kommen, übermittel ich einfach die doppelte Datenmenge und vergleich die empfangene Nachricht. Bei Nichtübereinstimmung würde ich das Paket dann einfach verwerfen.

Farbauti hat geschrieben:Sehr cooles Projekt. Auch wenn ich zur Zeit noch ein wenig an der Sinnhaftigkeit zweifle ^^'

Ich sag dann einfach mal danke.

Farbauti hat geschrieben:Stellst du den Source eigentlich zur Verfügung? Mir wäre so als hätte ich dazu mal was gelesen aber ich finde es nicht mehr oÔ

Das gesamte Projekt inklusive aller Quellcodes und CAD-Design ist open hardware und wird zu einem gegebenen Zeitpunkt unter einer BSD 3-Klausel-Lizenz veröffentlicht (mit Ausnahme des IP stacks vom tuxgraphics der unter der LGPL 2-Lizenz steht).

Habe aber die Erfahrung gemacht, dass es sinnvoll ist von Vornherein ein funktionierendes (wenn auch nicht unbedingt fertiges) Produkt zu veröffentlichen statt etliche Pre-Alphas, Alphas, Betas etc. an denen man schnell die Lust verliert. Dadurch ist schon so manches cooles Projekt den Bach runtergegangen.

Nichtsdestotrotz ist die bisherige Arbeit nicht geheim oder so und ich schicke auf Anfrage gerne den ein oder anderen Codeschnippsel.

johker hat geschrieben:Normalerweise wird im Spielebereich meistens UDP benutzt aufgrund des erwähnten Overheads bei TCP. Die Frage ist natürlich in wie weit der Overhead bei dieser geringen Datenmenge ins Gewicht fällt und ob es wirklich wichtig ist, dass alle Pakete ankommen. Das lässt sich sicher nur durch Tests feststellen.

+1. Jap, da helfen vermutlich nur Tests aber ich glaube nicht, dass es wirklich relevant sein wird.

johker hat geschrieben:Ich finde das Projekt auch extrem interessante und freue mich immer, wenn es hier einen neuen Beitrag gibt. Weiter so!

für die Motivation.

Und noch etwas in eigener Sache: und zwar ist mir der Gedanke gekommen, dass man dieses Projekt (ohne allzu großem Aufwand) auch für andere Systemen adaptieren könnte. Stichwort: Cross-platform Multiplayer – den Mega Drive-Spielern mal zeigen wo der Hammer hängt. Nur so als Hirngespinst.

Grüße
Micha

mupfelofen-de hat geschrieben:

Farbauti hat geschrieben: Habe grad nochmal nachgelesen: Das bilden einer Prüfsumme kann man auch bei UDP machen. Das war mir neu...

Da es das erste Mal ist, dass ich mich überhaupt mit Socket-Programmierung und dem Programmieren von Internet-Anwendungen auseinandersetze, habe ich auch erst beim Stöbern im Netz darüber gelesen. Aber eine echte Prüfsumme wie z.B. CRC-16 wäre wahrscheinlich unnötig. Ich mein, ich übertrage gerade mal 2 Byte Controller-Daten und weitere 1 bis 2 Byte um den Server herumzukommandieren.
Sollte es hier wirklich zu Problemen oder unkontrolliertem Verhalten im Spielbetrieb kommen, übermittel ich einfach die doppelte Datenmenge und vergleich die empfangene Nachricht. Bei Nichtübereinstimmung würde ich das Paket dann einfach verwerfen.

Das an dieser Stelle wahrscheinlich sinnvollste ist ein zusätzliches parity bit.

Viel Erfolg weiterhin! =)

d4s hat geschrieben:Das an dieser Stelle wahrscheinlich sinnvollste ist ein zusätzliches parity bit.

Simpel und einfach zu implementieren. Danke.

d4s hat geschrieben:Viel Erfolg weiterhin! =)

Merci!

Im Augenblick habe ich jedoch noch Probleme beim Auslesen der vom Server gesendeten Daten.

Ein kurzes Status-Update:

Ich habe inzwischen herausgefunden wie das SNESoIP die Server-Antwort einlesen und verarbeiten kann.
Im Augenblick sendet das Gerät 4 Bytes an einen Server; 2 Bytes beinhalten die Controller-Eingaben, 1 Byte die eigene Geräte-ID und das übrige Byte sagt dem Server, wessen Daten zurückgeschickt werden sollen.

Die gesendeten Daten werden dann auf dem Server in einem Array unter der eigenen ID hinterlegt.

Die Antwort besteht dann lediglich aus 2 Byte und beinhaltet die Controller-Eingaben der angeforderten ID.

So weit, so gut. Das mit dem ersten Level von Zombies (wie im vorherigen Video) habe ich auch schon probiert und es erfolgreich durchgespielt. Mit der Ausnahme, dass die Daten dieses Mal wirklich über den Server liefen und erst von dort aus zurückgesendet wurden.

Das Ganze funktioniert (im Augenblick) jedoch nur in meinem lokalen Netzwerk, da ich ARP noch nicht implementiert habe. Das ist dann aber als nächstes dran.

Außerdem habe ich noch ein Problem feststellen können. Und zwar sind einige Spiele wie z.B. Super Mario World über das SNESoIP noch nicht spielbar. Es lässt sich nicht richtig steuern und reagiert nicht korrekt auf die Eingaben am Controller. Das liegt vermutlich einfach am Timing und der Art und Weise wie die Daten an das SNES übertragen werden. Werde da einfach noch etwas herumexperimentieren, auch wenn ich nicht allzu viele Spiele im Schrank hab.

Grüße
Micha

PS: Die verwendete MAC-Adresse beginnt mit 00:09:BF und Wireshark ist so freundlich, es direkt als Nintendo-Hardware zu identifizieren.

Nachtrag: Ich habe außerdem noch ein kleines Feature implementiert, damit man nichts umstecken muss, wenn man als Spieler 2 spielen möchte. Und zwar werden die Daten einfach softwareseitig verdreht, wenn man Y und B beim Booten hält. Im Quellcode ist ist das der sogenannte Switched mode. Jetzt fehlt nur noch das Konfigurations-Interface und die Möglichkeit sich über das Internet zu verbinden. Sobald das klappt, beginne ich mit dem Layout der Platine.

Ich habe ARP nun implementiert und SNESoIP erkennt nun, ob sich der Server im LAN oder im Internet befindet.
Allerdings erkenne ich eine minimale Verzögerung beim Testen über das Internet; die empfangenen Daten werden, falls ich mich nicht täusche, einen kurzen Augenblick später an das SNES übertragen.

Ich denke, so langsam benötige ich ein zweites SNES oder zumindest mal einen simulierten Client.