8Bitdo Retro Receiver (SNES / SFC)

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Meine waren nun pünktlich gestern da. Wirklich ordentlich! Die Buttons sind noch so knackig und unabgenutzt, völlig ungewohnt :s000:

      Tipp: Wer den SNES-Receiver nutzt, sollte bei diesem direkt ein Firmwareupdate auf die aktuelle Beta machen. Die vorprogrammierte Version 1.20 hat Bitverschiebungen bei Spielen, die kein Auto Joypad Read nutzen, somit wird entweder gar kein Controller erkannt oder es werden falsche Knöpfe gedrückt.

      Download hier: forum.8bitdo.com/thread-1404-1-1.html (man muss sich leider registrieren)
      ^o^)~

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von ikari_01 ()

    • ikari_01 schrieb:


      Tipp: Wer den SNES-Receiver nutzt, sollte bei diesem direkt ein Firmwareupdate auf die aktuelle Beta machen. Die vorprogrammierte Version 1.20 hat Bitverschiebungen bei Spielen, die kein Auto Joypad Read nutzen, somit wird entweder gar kein Controller erkannt oder es werden falsche Knöpfe gedrückt.
      Ich hoffe, das Ding updated die Daten schnell genug für den uIGR!? Das war ja schon bei den Dingern von retro-bit n Krampf... Oder ich sollte doch so langsam vom Mikrocontroller auf n CPLD umsteigen :s000:


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub
    • Nach dem Update schon, denke ich. Kann ja mal nachgucken. Wie schnell muss es für den uIGR sein?

      EDIT: Hm, nicht so sicher... manchmal resettet das U16 schon bei L+R+Select. Hooks am sd2snes sind aus. Die Super-Star-Wars-Spiele machen aber irgendwie auch besonders fieses joypad read. :s000:
      ^o^)~

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von ikari_01 ()

    • Nach der negativen Flanke am Clock wartet der uIGR bis die Clockleitung wieder high ist, wartet noch 1us (im Modi für den retro-bit controller 3us) und liest dann an der Datenleitung.

      Also durch die Abfragen, Sprünge und Setup-Time im worst-case:
      • Wenn das SNES AJR benutzt, hat der Receiver knapp 7us (9us) zum Umschalten.
      • Wenn das SNES kein AJR benutzt (Clock geht sofort wieder auf high) , hat der Receiver max. 1.5us (3.5us) Zeit zum Umschalten
      Der wireless Receiver von @micro schafft im Übrigem die 1.5us und ist damit deutlich schneller als die alten Dinger von retro-bit :thumbup: (sollte mal gesagt sein)


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub
    • Meine Zeiten sind von der neg. Clockflanke angegeben; dort tastet die S-CPU ja ab (anders als dokumentiert; der uIGR halt früher nach Orientierung an der pos. Vorgängerflanke bzw. dem Latch). Wird also knapp im 'normalen' Abtastmodi - kann mal passen, muss aber nicht. Im 'verzögertem' Abtastmodi passt es gut.

      Nach der pos. Flanke vom Latch braucht der MC übrigens 3us (3.5us) inkl. Jump(s).

      Nicht alle uIGRs haben den Modi für die wireless retro-bit Controller. Das war die letzte Änderung, die ich letzten Dezember eingebaut hatte. Naja, zur Not kann man den uIGR ja ausschalten ;)


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub
    • Jop, die CPU übernimmt auf negativer Flanke, auf positiver liefert der Controller die Daten. Dabei ist zu beachten, dass die CPU natürlich erst bei der nächsten negativen Flanke die Daten übernimmt. Mit dem PIC inkl. IRQ-Latenz kriegt man aber auf dieselbe Weise wohl kein Sampling hin, bis dahin hat ein schneller Controller schon das nächste Bit auf der Leitung - bei manuellem Read sind die Low-Zeiten ja extrem kurz mit 380ns.

      Bleibt halt nicht viel über als auf die positive Flanke (latch oder clock) zu warten (deren Position ist, was die Bedeutung fürs Timing der Controllerdaten angeht, immer identisch) und möglichst schnell - aber wohl nicht ZU schnell :s000: - die Daten zu samplen, mit den damit verbundenen Problemen unterschiedlicher Controllerlatenzen... :/

      Beim sd2snes Ingame-Hook ist die Zeit zwischen positiver und negativer Clock-Flanke ca. 4,3µs - das dürfte die retro-bit Dinger wohl killen :s000:

      Alternativ könnte man im PIC ein kleines (Schiebe?)register mitlaufen lassen, das die Datenleitung permanent samplet. Kommt ein Interrupt (fallende CLK), nimmt man das zuletzt gespeicherte Sample (oder n-1?) und hat so maximale Sicherheit durch minimalen Abstand zum tatsächlichen S-CPU-Sampling. (Symbolfoto mit Testflüssigkeit hier dazudenken.) Was der PIC dann nicht sieht, sieht die S-CPU auch nicht, und dann hat man ein ganz anderes Problem :s000:

      Hups, derailed. Naja :saint:
      ^o^)~
    • ikari_01 schrieb:

      Jop, die CPU übernimmt auf negativer Flanke, auf positiver liefert der Controller die Daten. Dabei ist zu beachten, dass die CPU natürlich erst bei der nächsten negativen Flanke die Daten übernimmt.

      Ja ich weiß :s000:
      (hatte es nur nicht so klar geschrieben -> "positive Vorgängerflanke bzw. Latch")

      ikari_01 schrieb:

      Bleibt halt nicht viel über als auf die positive Flanke (latch oder clock) zu warten (deren Position ist, was die Bedeutung fürs Timing der Controllerdaten angeht, immer identisch) und möglichst schnell - aber wohl nicht ZU schnell :s000: - die Daten zu samplen, mit den damit verbundenen Problemen unterschiedlicher Controllerlatenzen... :/

      Beim sd2snes Ingame-Hook ist die Zeit zwischen positiver und negativer Clock-Flanke ca. 4,3µs - das dürfte die retro-bit Dinger wohl killen :s000:


      So ist es halt jetzt. Ich hatte mich bei dem verzögertem Abtasten auch an dem sd2snes Ingame-Hook orientiert. Da ich befürchte, dass das 'verzögerte Abtasten' auch mal zu lange dauert (man muss ja noch wegspeichern), ist der Modi halt optional.

      Du brauchst dir keine Gedanken um die Retro-Bit Dinger machen. Die sind eh gräßlich bis unspielbar. Da scheint der Controller und die Kommunikation zw. Controller und Receiver das übliche beizutragen.

      ikari_01 schrieb:

      Alternativ könnte man im PIC ein kleines (Schiebe?)register mitlaufen lassen, das die Datenleitung permanent samplet. Kommt ein Interrupt (fallende CLK), nimmt man das zuletzt gespeicherte Sample (oder n-1?) und hat so maximale Sicherheit durch minimalen Abstand zum tatsächlichen S-CPU-Sampling. (Symbolfoto mit Testflüssigkeit hier dazudenken.) Was der PIC dann nicht sieht, sieht die S-CPU auch nicht, und dann hat man ein ganz anderes Problem :s000:

      Habe ich auch so mal gemacht, war aber eher eklig. Das hat recht schlecht funktioniert; gerade, wenn AJR nicht genutzt wurde. Das permanente Abtasten und Wegspeichern brauchte zu viel Zeit.

      Also doch n CPLD ? Code passt in nen MaxV mit 570LE :s000:

      Zu viel Off-Topic... :rolleyes:


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub
    • borti4938 schrieb:

      Also doch n CPLD ? Code passt in nen MaxV mit 570LE :s000:
      Oder einen Mikrocontroller, der einen Timer mit Capture-Eingang hat - beim Pegelwechsel auf der Clock-Leitung kann man dann nachschauen, wie viel Zeit seit dem letzten Pegelwechsel auf der Datenleitung vergangen ist. Oder man klemmt die Signale an ein Hardware-SPI des Mikrocontrollers und lässt die Abfrage in Hardware erledigen.
    • An den Timer hatte ich noch so nicht gedacht, aber an das SPI Interface.

      Mit nem selbstgeschrieben SPI hat es mal angefangen. Anschließend dachte ich mir: ach, dies noch, das noch, jenes noch... Und whoops; plötzlich war der gesamte uIGR im CPLD. :s000: (Grund für den CPLD war das Zusammenführen verschiedener Aufgaben, die parallel erledigt werden sollen.)
      Aber alles nur just for fun geschrieben


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub
    • Habe mal den Stromverbrauch eines SNES-Receivers gemessen:
      - 50mA im Pairing/Suchmodus
      - 33mA idle oder wenn eine Buttonkombination gedrückt gehalten wird
      - 44-45mA, wenn Knöpfe gedrückt werden (je nachdem wie viele und wie schnell).

      Recht viel, für Multitap-Einsatz daher wohl eher eingeschränkt zu empfehlen oder nur mit Schaltregler im SNES ;)
      ^o^)~

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von ikari_01 ()

    • ikari_01 schrieb:

      Habe mal den Stromverbrauch eines SNES-Receivers gemessen:
      - 50mA im Pairing/Suchmodus
      - 33mA idle oder wenn eine Buttonkombination gedrückt gehalten wird
      - 44-45mA, wenn Knöpfe gedrückt werden (je nachdem wie viele und wie schnell).

      Recht viel, für Multitap-Einsatz daher wohl eher eingeschränkt zu empfehlen oder nur mit Schaltregler im SNES ;)
      Bedeutet also, dass ich 2 Receiver an der Konsole ohne Probleme benutzen kann?
    • Streng genommen nicht in Verbindung mit einem SuperFX-Spiel (oder einem sd2snes). Aber Nintendo hat damals eher konservativ gerechnet denke ich, jedenfalls liegt man rechnerisch immer noch unter der Kapazität von Netzteil und Linearregler. Ich habe den Eigenbedarf des SNES leider nicht mehr im Kopf, nur, dass da noch Luft nach oben war.
      ^o^)~
    • Hallo Leute,

      Ich habe mir ein SFC30 Pad gekauft und muss sagen, dass ich absolut verliebt in das Teil bin. Ich bin natürlich kein Experte...aber die Verarbeitung ist klasse, die Tasten fühlen sich besser an als jedes SNES Pad das ich jemals in der Hand hatte (ich habe mein erstes SNES damals auch aus zweiter Hand bekommen). Es gibt nur das "Problem" mit der Verbindung an eine "physische" also echte Konsole. Es gibt ja nur diesen Wireless Empfänger, oder? Ein USB to SNES Kabek habe ich dafür ja noch nirgends gesehen.
      Nachdem ja @ikari_01 offensichtlich so ein Teil zuhause hat wollte ich fragen ob er (oder gern auch andere) mal die 240p Test Suite für Input Lag fahren könnten?
      Weil dann werde ich entscheiden ob ich das Teil behalten kann oder es schweren Herzens (als nutzlos wegen Lags) zurückschicken muss?


      Wäre wirklich äußerst dankbar
    • Um mich selbst zu zitieren:

      Ich merke keinen Unterschied zum Kabelcontroller, was aber nicht viel heißen muss. sd2snes-Menü und Hexmonitor bedienen sich aber sehr schwuppdiziös und die nutze ich ziemlich intensiv in letzter Zeit.
      Man sollte auch nicht vergessen, dass das SNES den Controller in der Regel ohnehin nur alle 16-20ms überhaupt abfragt.


      Ich wüsste übrigens nicht, wie ich mit der 240p Suite zu einem aussagekräftigen Ergebnis kommen sollte, man möge mich erhellen ;)
      ^o^)~
    • Ich wüsste zwar nicht wie ich den Macher des SD2SNES irgendwie erhellen sollte...aber ich schau halt manchmal Mylifeingaming...



      wäre meine Idee?

      Und du meintest das SNES fragt nur alle 16-20 ms ab? das heisst ja dann schon input lag von 1 frame von haus aus? ODER?
    • Zwischen 0 und 16 (60Hz) bzw. 20ms (50Hz), je nachdem wann innerhalb dieses Zeitrasters du den Knopf drückst.
      Die 240p-Variante dürfte zu ungenau sein, man kann damit nur mit einer Auflösung von einem Frame messen und ich gehe derzeit davon aus, dass die Verzögerung durch den Controller eher darunter liegt. Mal was überlegen...
      ^o^)~
    • Ok na 16 ms würden ja eh passen also standard Input lag bei 60 fps in Spielen...das wäre ja sozusagen Standard.
      In der 240p kann man zumindest auf 1 Frage genau messen...natürlich müsste man das ganze ein paar mal machen um "menschliches Versagen" auszuschließen.
      Oder meinst du 240p Lag test misst nicht genau genug um überhaupt einen Unterschied zu messen?
      Wenn du zuerst mit einem normalen Verkabelten SNES Pad 5 Durchgänge machst und dann 5 mit dem Receiver wireless sollte man doch einen eventuellen Unterschied in Frames messen können? Oder denk ich da falsch?
      Überlegst du dir etwas anderes?
    • Das Problem ist, dass ich das gar nicht genau genug abpassen kann (+/- 3 Frames - mit einem Kabelcontroller) bzw. ich während des Tests automatisch lerne, den Score zu minimieren. Durch die Hirnkomponente verfälscht sich das meiner Meinung nach von selbst ;)
      ^o^)~
    • Hast du etwas anderes im Kopf? Aber wenn 3 Frames immer auch mit dem Kabel variable sind warum spiele sich Emulatoren dann so "komisch"/verzögert? Hab jetzt einen Retron 5 probiert an einem total schnellen Gaming IPS Monitor und das war furchtbar...
    • Öh, na weil diese Systeme eigene Verzögerung produzieren. Ist halt nur Android, wo ein Emulator drauf läuft. Ich wollte damit nur sagen, dass ich mich nicht eigne, mit so einem dings Lag zu testen. :)

      Ich würde wohl einen kleinen Codeschnipsel am SNES laufen lassen, der nichts anderes tut als permanent den Controller abzufragen (nicht nur einmal pro Frame). Dann einen Logicanalyzer z.B. an den B-Knopf des Controllers hängen und zusätzlich an die seriellen Daten des Controllerports am SNES. Dann kann man auf einer Zeitleiste sehen, wann der Knopf gedrückt wird und wie lange es dauert, bis er am Controllerport auftaucht.
      Wenn ich mal Zeit hab. :s000:
      ^o^)~
    • @Ikari_01: Ich glaube ich verstehe dein Argument jetzt. Aber es ist doch in der Praxis so: Wenn du mit dem eigentlich für Display Lag ausgelegten 240p Tests an ein und demselben Display die Test machst und lediglich den Controller wechselst würde ein eventuell gemessener Lag offensichtlich von Controller ausgehen (der Test misst ja nur wie schnell die Eingabe erfolgt in Relation zu dem was man optisch am Bildschirm sehen kann).

      Was ich sagen möchte: Ich wäre dir sehr dankbar wenn du diesen (nicht wirklich total wissenschaftlichen) Test kurz für mich absolvieren könntest...ich muss nämlich mein Gamepad entweder übermorgen zurückschicken oder endgültig behalten.

      Aber es wäre natürlich noch interessanter deine Profi Messung zu studieren ;)
    • Wie er schon schrieb: aus statistischer Sicht (und auch aus praktischer Sicht) ist dieser Test absolut unbrauchbar! Zum einen durch die menschliche Komponente und zum anderen durch den Fakt, dass negative Werte gestrichen werden, obwohl diese zur Statistik (um menschliche (Vor-)reaktionsweit rauszumitteln).

      Ich sage zu 95%, dass der Controller 'besser' ist, den Ikari als zweites testet. Egal ob nun kabelgebunden oder wireless. :P


      Ich verkaufe recht selten Moddingsachen > Bitte schreibt mir keine PNs mit direkten Anfragen. Manchmal habe ich etwas im Trödel gelistet.
      Bitte keine allg. Fragen per PN > Allgemeine Fragen gehören ins Forum - dafür ist es ja da - und nicht per PN an mich.

      Projekte: GitHub
    • @borti4938: Gut aber dann könnte er ja auch das ganze 4x machen (zuerst mal Kabel dann Wireless, dann Wireless und Kabel). Aber das mein Vorschlag nicht die letztgültige Analyse sein kann war mir eh klar. Mir gehts nur drum ob ich das Teil gleich loswerden sollte oder ob ich es doch behalte.

      Danke für die Mühe @ikari_01