[Support] Atmosphère Datei emuMMC (emuNand) manuell oder automatisiert einrichten

  • 1. muss der Emunand bei neuen Versionen auch neu erstellt, um zu sehen ob er nun schneller läuft, oder reicht hier einfach das Updaten von Atmosphere XL?

    Wenn sich an den Verweisen in der emummc.ini nichts ändern sollte, ist alleine nur das Aktualisieren von AtmoXL ausreichend. Sollte sich jedoch etwas ändern (wovon ich zunächst einmal nicht ausgehe) wird sich das nicht auf das emuMMC Image und den installierten Content auswirken, sondern nur auf eine Änderung in den Einträgen der emummc.ini, was auch eine Umstrukturierung der Ordner nach sich ziehen würde. Eine Neueinrichtung des emuMMC ist dann jedoch nicht erforderlich.



    2. Ich werde mir demnächst eine größere SD Karte besorgen (dümpel auf 64 GB rum ) Reicht es hier einfach 1:1 die Dateien zu kopieren, oder muss ich den Emunand Erstellprozess hier zuerst neu durchführen?

    Nein, wenn du einen Datei emuMMC eingerichtet haben solltest, brauchst du nur die SD-Karte 1 zu 1 kopieren.



    3. Wenn ich Retroarch auf dem Emunand laufen lassen will, muss dieser trotzdem ins Root Verzeichnis der SD Karte, oder unter den Ordner des Emunand?

    Die Retroarch NRO liegt im switch Ordner und ist damit unabhängig davon, ob die CFW nun im sysMMC oder emuMMC ausgeführt wird. In dieser Hinsicht brauchst du nichts weiter zu unternehmen.

  • Ich komme gerade aus einem anderen Thread den ich nicht weiter offtopic zu müllen möchte, Deswegen frage ich hier ganz blöde nach:


    Wenn ich sowieso nicht mit meiner Konsole online gehe möchte und daher keine zwei "seperaten Systeme" benötige. Welche vorteile habe ich dann durch ein emuMMC? Meine Fuses brennen nicht durch (würde von 7.0.1 auf 8.1.0 updaten) aber wofür brauche ich diese Fuses? Die verindern doch nur das downgrade auf eine ältere Firmware oder?

  • @punki Das mit dem "sauber bleiben" betrifft ausschließlich nur den sysNand (eMMC). Für den emuMMC /emuNand ist das völlig wurscht :)
    Meines Wissens, gibt es nur den Weg über einen Werksreset, um den sysNand wieder sauber zu bekommen (abgesehen von einem Nand Restore eines Backups von einem sauberen sysNand, was aber immer mit einem gewissen Brickrisiko verbunden ist)



    Meine Fuses brennen nicht durch (würde von 7.0.1 auf 8.1.0 updaten) aber wofür brauche ich diese Fuses? Die verindern doch nur das downgrade auf eine ältere Firmware oder?

    Mit einem Update von FW 7.x auf FW 8.1.0 wird eine weitere eFuse gebrannt (ausgenommen du aktivierst AutoRCM, was ein Booten in die OFW jedoch verhindert)! Der emuMMC hat auch den Vorteil, dass bei einem Fehltritt dein "echter" Systemspeicher keinen Schaden erleidet. Es könnte also im schlimmsten Fall unter einem sysNand zu einem Brick kommen, während unter den gleichen Umständen auf einem emuMMC nur die Image Dateien unbrauchbar werden würden und bei einer vorliegenden Sicherung die Daten problemlos wieder hergestellt werden könnten.

  • Danke für die ausführliche Info MUXI. Da ich eigentlich recht vorsichtig mit der Switch bin und nur das nötigste daran verändere (und dann vorher auch lieber noch mal nachfrage) denke ich werde ich bei dem klassichen Vorgehen bleiben.


    Ich muss aber leider noch mal was nachfragen (hänge nämlich auch gerade in der Anleitung an dem Punkt) Wenn ich jetzt ChoiDujourNX nutze muss ich mich entscheiden ob ich eine Fuse brenne und theoretisch in die OFW komme oder Sie nicht brenne und nur noch in die CFW komme. Nach meinem Verständnis könnte bzw. müsste ich bei letzterer Entscheidung aber wieder über ChoiDujourNX die 7.0.1 aufspielen können und die dann auch als OFW ganz normal booten können weil die Anzahl der gebrannten Fuses dann wieder stimmt. Ist das so richtig? Dann würde ich nämlich lieber AutoRCM an lassen da ich eigentlich sowieso nur CFW brauche und ggf. ja auch wieder zurück könnte (warum auch immer das mal nötig sein sollte).

  • @punki Ich sagte ja bereits, dass ein Werksreset die sicherste Methode ist, das System im sysNand wieder sauber zu bekommen. Ein Restore des 5.x Backups wäre 1. mit einem Brick-Risiko verbunden und 2. mit dem Aufwand verbunden, diese FW wieder updaten zu müssen (wegen der eFuses-Inkompatibilität, wenn zuvor eine höhere FW Version auf der Konsole installiert war), was nach meinem Dafürhalten aber wiederum nur offline über eine CFW möglich ist (weil du nicht in die OFW booten, und somit die FW nicht online aktualisieren kannst). Und dann stündest du wieder da, wo du dich am Anfang befunden hast - vor einem verunreinigten sysNand!


    @berndschroed Wenn du von der FW 7.x auf FW 8.1.0 updatest, OHNE AutoRCM zu aktivieren, dann wird zwangsläufig durch das Booten in die OFW eine weitere eFuse gebrannt. Das ist nicht mehr rückgängig zu machen, auch nicht durch einen Downgrade. Wenn du jedoch AutoRCM bei dem FW Update aktiviert hast, werden keine eFuses gebrannt (solange du nicht AutoRCM wieder deaktivierst und dadurch in die OFW bootest) Erst wenn du wieder über ChoiDujourNX auf eine FW zwischen 7.0.0 und 8.0.1 gedowngradet hast, kannst du gefahrlos AutoRCM wieder deaktivieren. Allerdings ist AutoRCM auch nicht zu unterschätzen, da du nicht mehr erkennen kannst, ob deine Konsole ausgeschaltet ist, was zu einer Tiefenenrladung des Akkus führen kann. Wenn du auf Nummer Sicher gehen möchtest, solltest du besser einen emuMMC einrichten und diesen auf FW 8.1.0 aktualisieren. Dann kann auch auf AutoRCM verzichtet werden. Allerdings müsstest du unter einem Datei emuMMC derzeit noch sehr geduldig mit den Boot- und Ladezeiten sein, bis eine Optimierung erfolgt ist.

  • Kein Problem :) . Du solltest aber nicht vergessen, auf die FW Version 7.0.0-8.0.1 zu downgraden, bevor du AutoRCM wieder deaktivierst. Du könntest auch schon jetzt einen Datei-emuMMC einrichten. Dann hättest du schon mal einen 8.1.0 emuMMC angelegt. Mit dem Tool emuMMC-toggle kannst du ihn nach der Einrichtung wieder deaktivieren und dann erst wieder reaktivieren, wenn er entsprechend optimiert worden ist.

  • Hallo zusammen,


    habe mir ein emuMMC nach der automatischen Methode eingerichtet. Dauerte auch nur 15 min.
    Habe dann über ArgonNX Atmospere gestartet, dauerte dann auch eine Weile.
    Wenn ich dann auf dem Startbildschirm dreimal mit A bestätigen soll, öffnet sich das Home-Menü kurz dann wird der Bildschirm wieder schwarz
    und es erscheint eine Fehlermeldung:
    Fehlercode: 2016-0247 "Es konnte nicht auf die microSD Card zugegriffen werden"
    Habe zuvor ein Werksreset durchgeführt.
    Hat jemand eine Idee?


    Gruß scout

  • Hast du mal die SD-Karte entnommen und wieder eingesteckt? Möglicherweise besteht ein Kontaktproblem. Wie hast du deine SD-Karte denn formatiert?

  • SD Karte ist in FAT32 formatiert.
    Habe SD Karte mal rausgenommen und wieder eingesteckt - Problem besteht weiterhin.
    Wenn ich Fehlermeldung mit Schließen bestätige, kommt das Home-Menü.
    Gehe ich die Systemeinstellung unter Datenverwaltung ist die SD Karte ausgegraut.
    Als Systemversion wird 8.1.0 (0.9.2) angezeigt.
    Öffne ich über das Album mit gedrückter R-Taste das Homwbrew Menu kommt dies auch.
    Dauert der Ladevorgang eigentlich nur solange bis das Switch Symbol verschwindet?

  • Hast du diese SD-Karte schon länger im Einsatz? Nintendo schreibt zu dieser Fehlermeldung folgendes:
    https://en-americas-support.ni…~/error-code%3A-2016-0247


    Ich würde mal den Inhalt der SD-Karte auslagern und auf eine andere nach FAT32 formatierte SD-Karte kopieren, um zu sehen, ob das Problem dadurch behoben ist.


    Dauert der Ladevorgang eigentlich nur solange bis das Switch Symbol verschwindet?

    Der Bootvorgang dauert sehr lange. Die Navigation unter dem emuMMC ist auch etwas verzögert in der Reaktion, im Gegensatz zum sysMMC. Allerdings sind Spiele i.d.R. davon im laufenden Betrieb nicht betroffen (Jedenfalls kann ich das für die von mir getesteten Spiele so bestätigen) .

  • SD Karte ist Neu. Ist ein SanDik Ultra 200GB. Sollte eigenlich passen.
    Nicht das ich einen Denkfehler habe.
    Der emuMMC Ordner ist zusätzlich zu sämtlichen Dateien aus dem Atmosphere XL Paket auf der SD Karte.
    Die Ordnerstruktur ist im Anhang.
    Wenn ich den emuMMC Ordner lösche und dann starte funktioniert alles einwandfrei.Dann wird im Systemmenü die SD Karte auch erkannt.


    Wass bedeutet denn "sehr lange" 2min -5min oder länger?

  • Der emuMMC Ordner ist zusätzlich zu sämtlichen Dateien aus dem Atmosphere XL Paket auf der SD Karte.

    Das ist auch alles richtig, aber ich würde es dennoch mal mit einer anderen SD-Karte versuchen. Es kann ja trotzdem ein Problem mit dieser SD-Karte vorliegen, auch wenn sonst alles andere bislang fehlerfrei funktionieren sollte. Das kannst du aber nur mit Gewissheit feststellen, wenn du das mit einer zweiten SD-Karte testest.



    Wass bedeutet denn "sehr lange" 2min -5min oder länger?

    Ich kann das gerade mal mit einer Stoppuhr messen.....Ein kleines Momentchen bitte......


    Edit:
    Der Reboot zum AtmoXL Datei-emuMMC, ausgehend vom SX OS über den Payloadlauncher bis zum Erscheinen des Switch Logos dauert etwa 2 Minuten und bleibt weitere 8:30 Minuten auf dem Display zu sehen, bis dann schließlich das Horizon des emuMMC erscheint - nach insgesamt 10:30 Minuten. Dann dauert es noch einen kurzen Moment, bis alle "Instanzen" geladen sind. Bis dahin reagiert die Navigation noch verzögert. Solange nun die Konsole über den Standby reaktiviert wird, ist die Geschwindigkeit nach meinem Dafürhalten ganz akzeptabel, aber keinesfalls vergleichbar mit der emuNand Datei-Variante des SX OS.


    Ich habe das unter der AtmoXL Version 5c140b4f (der inoffiziellen Version 0.9.3) mit einer Samsung EVO Plus 512 GB SD-Karte (FAT32) getestet.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!