Selbst dann müsste der emuMMC (Kein emuNAND) schneller sein.
Das hängt mit dem Dateisystem zusammen und deren Partitionsgröße.
Das kann einer wenn er mag testen
Selbst dann müsste der emuMMC (Kein emuNAND) schneller sein.
Das hängt mit dem Dateisystem zusammen und deren Partitionsgröße.
Das kann einer wenn er mag testen
Passiert im eifer des gefechts, Mods sind auch nur Menschen
Alles gut, ich sitze hier dann nur immer wieder völlig perplex in einem Sumpf von Selbstzweifeln!
Der Datentransfer auf einem Chip (eMMC) ist immer schneller, als auf einem Datenträger, wie in diesem Fall einer SD-Karte (und damit die dort emulierten eMMCs)
Das ist klar nur da waren eben zwei Buchstaben zuviel
Das kann einer wenn er mag testen
Wie will man das testen (mit der Switch)?
Der emuNand und emuMMC sind beide gleich groß (Alle 29GB)
Ich habe nun einen Test durchgeführt, wie es mit der Nutzung des SX OS und AtmoXL unter einem einzigen auf der SD-Karte eingerichteten Partition emuMMC aussieht. Es kann unter dem emuMMC installierter Content unter beiden CFWs genutzt werden, wenn in der emummc.ini der letzte Eintrag zu nintendo_path=Emutendo geändert wird. So kann ein emuMMC mit zwei unterschiedlichen CFWs genutzt werden. Das setzt die Einrichtung des Partition emuMMC über Option 2 (Einrichtung über das SX OS) aus dieser Anleitung voraus, und diese genannte Änderung in der dort zu beziehenden emummc.ini (natürlich muss auch ebenfalls eine gültige license.dat vorliegen).
Ist nicht der Unterschied zwischen EmuMMC und EmuNand lediglich die Partition- oder dateibasierte Variante, oder hab ich das falsch verstanden?
War das jetzt eigentlich richtig?
Nein, wenn wir von emuNand sprechen, geht es um das SX OS, und emuMMC ist die unter Hekate erstellte Variante, die unter Atmosphere eingesetzt wird. Diese sind dann jeweils noch in ihre Typen unterteilt (partition- oder dateibasiert).
Ich weiß schon warum ich gefragt hab
Worin unterscheiden die sich denn?
Der Unterschied liegt in der Aufteilung der Splitfiles. Das SX OS hat einschl. der boot0/1 10 Dateien, die Hekate Variante hingegen 17! Bei der Partition Variante ist auch die Lage entscheidend. Während das SX OS nur eine Partition unterstützt, die im vorderen Bereich auf der SD-Karte erstellt wurde, kann die Partition Variante von Hekate sowohl vorne, als auch hinten erkannt werden.
Das ist mir letztens aufgefallen, aber was genau hat das für Vor- und/oder Nachteile (wenn es denn überhaupt welche gibt) und warum ist die Bezeichnung anders?
Hinsichtlich der Partitionvarianten gibt es folgende Vor- und Nachteile:
Wenn der Partition emuMMC ( in dem Fall auch emuNand) über das SX OS erstellt wurde, wird die Partitionierung im vorderen Bereich vorgenommen und der emuNand dort erstellt. So kann er auch über Atmosphere genutzt werden. Allerdings lassen sich dann keine voneinander getrennten emuMMC Systeme mehr auf der SD-Karte nutzen.
Wenn der Partition emuMMC über Hekate erstellt wird, kann er nur von Atmosphere genutzt werden, was aber den Vorteil hat, dass ein SX OS mit einem Datei emuNand noch als eigenständiges System auf der gleichen SD-Karte verwendet werden kann.
Der Datei emuNand des SX OS hat auch noch den Vorteil, dass er einfacher zu handhaben ist, was das Sichern und Wiederherstellen, sowie den Umzug auf eine andere SD-Karte betrifft. Allerdings hat er auch Nachteile hinsichtlich von RCM Payloads, wie Lockpick und Incognito, da diese darauf nicht zugreifen können.
Ich meinte jetzt mehr wenn man nur das eine oder andere nutzt, also keinen Mischbetrieb?
Es muss doch einen Grund haben das die Systeme unterschiedlich verfahren?
Den Datei emuMMC kann man außen vor lassen, weil er unoptimiert ist. Bleiben nur die 3 anderen Varianten:
SX OS Datei emuNand
SX OS Partition emuNand
Partition emuMMC
Von der Leistung her sind alle nahezu identisch. Die Datei-Variante lässt sich einfacher handhaben, wie in meinem letzten Post bereits ausgeführt. Das ist hingegen ein Nachteil der Partition Varianten (wobei dies mittlerweile m.E. zu vernachlässigen ist - vor Monaten sah das noch anders aus)
Die Partition Varianten haben hingegen den Vorteil, dass RCM Payloads auf sie zugreifen können (was m.E. ein gravierender Nachteil der Datei Variante ist!)
Das ist hingegen ein Nachteil der Partition Varianten (wobei dies mittlerweile m.E. zu vernachlässigen ist - vor Monaten sah das noch anders aus)
Auf eine andere Karte umziehen ist mit einem dateibasierten aber immer noch einfacher und schneller oder?
Die Partition Varianten haben hingegen den Vorteil, dass RCM Payloads auf sie zugreifen können (was m.E. ein gravierender Nachteil der Datei Variante ist!)
Was wiederum bei Nutzung von nur einer CFW auch wieder egal ist?
Auf eine andere Karte umziehen ist mit einem dateibasierten aber immer noch einfacher und schneller oder?
Natürlich, du brauchst nix zu partitionieren und kopierst nur von A nach B
Was wiederum bei Nutzung von nur einer CFW auch wieder egal ist?
Das hat nichts mit der Nutzung von nur einer CFW zu tun. Es ist schon vorteilhaft, wenn man beispielsweise seine aktuellsten Keys aus einem Partition emuMMC auf FW 9.0.x auslesen kann, während der sysNand noch auf FW 3.0.0 ist! Das wäre mit einem Datei emuNand nicht möglich.
Mein ich doch, aber warum ist das mittlerweile zu vernachlässigen?
Es ist schon vorteilhaft, wenn man beispielsweise seine aktuellsten Keys aus einem Partition emuMMC auf FW 9.0.x auslesen kann, während der sysNand noch auf FW 3.0.0 ist! Das wäre mit einem Datei emuNand nicht möglich.
Ich habe ja nur SX OS mit Datei Emu, aber ich kann doch auch eben Lockpick booten wenn ich eben den Loader umstelle und dann die Keys aus dem Emunand auslesen?
warum ist die Bezeichnung anders?
Die Frage ist noch offen, weißt du das?
Es kann unter dem emuMMC installierter Content unter beiden CFWs genutzt werden, wenn in der emummc.ini der letzte Eintrag zu nintendo_path=Emutendo geändert wird. So kann ein emuMMC mit zwei unterschiedlichen CFWs genutzt werden. Das setzt die Einrichtung des Partition emuMMC über Option 2 (Einrichtung über das SX OS) aus der Anleitung voraus, und diese genannte Änderung in der dort zu beziehenden emummc.ini (natürlich auch ebenfalls eine gültige license.dat).
Genau so ist das. Anbei meine emummc.ini
So lässt sich zwischen Atmosphere und SX OS hin un her mit dem emuMMC switchen und man den kompletten Contend, sprich Spiele, Spielstände, Homebrew etc.
Genau so ist das. Anbei meine emummc.ini
...wobei bei mir der Eintrag unter "path" unverändert geblieben ist. Wahrscheinlich ist das aber für die Funktion auch bedeutungslos. Das mit den Homebrew würde auch für die getrennten emuNands gelten, da ja beide auf den "gemeinsamen" switch Ordner zugreifen
Ach ja, incognito RCM geht jetzt auch und kefir und das mit SX OS....
Ich habe ja nur SX OS mit Datei Emu, aber ich kann doch auch eben Lockpick booten wenn ich eben den Loader umstelle und dann die Keys aus dem Emunand auslesen?
Tatsächlich? Dann muss sich mittlerweile etwas geändert haben, denn das war immer nur mit Lockpick als HB-Tool möglich, aber nur bis zu den 5er Keys. Ich kann das nicht mehr prüfen, da ich auch einen Partition emuMMC auf der SD-Karte habe, und ich annehmen muss, dass die Keys aus diesem ausgelesen werden. Aber ein anderes Beispiel ist der Incognito RCM, wie @Guybrush2012 über meinem Beitrag bereits berichtet hat
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!