dem1980

Hello, j'ai démarré le HBL en maintenant le bouton R sur la home sous SX OS, le core PSP se charge bien, mais au lancement d'une ROM, la console freeze avec un code erreur... Que doit-je faire ? Merci par avance. ^^

Mouais chez moi la console plante de suite ...J vais attendre des retours.

@dem1980 : Pour bien comprendre il te faut décomposer SX OS en deux phases, la première est le payload "SX Loader" qui fonctionnera quelque soit le firmwares d'une Switch non patchée et la seconde phase est le lancement du CFW, phase qui ne fonctionnait pas en firmware 7.0.X avant cette version 2.6. De fait, quand on lance l'emunand avec SX OS, on boot donc d'abord sur le loader puis on boot l'emunand, cette phase ayant la particularité de rediriger les différents flux vers la SD avant de faire un soft reboot (en gros) puis de lancer le firmware stocké dans l'emunand, raison pour laquelle même avec une configuration Sysnand 7.X et emunand 6.2.0 il était possible de lancer SX OS en emunand. Du coup non, SX OS n'était pas compatible 7.0.X avant alors que maintenant oui, on peut lancer SX OS sur la sysnand et sur l'emunand en 7.0.X, avant c'était juste le fonctionnement de l'emunand qui était exploité pour la lancer car le firmware 7.X n'était en fait jamais chargé par la phase deux, le lancement du CFW. J'espère t'avoir un peu mieux éclairé.

@BostonCeltics : Tien bah toi tu est le parfait spécimen des personnes que je décris dans mon paragraphe suivant, pour rappel voici l'article en question qui est plutôt objectif contrairement à se que tu semble prétendre et qui avait juste pour but de clarifier les choses.

C'est fou, à chaque fois qu'on a une news sur SX OS c'est du grand n'importe quoi les commentaires et ça suit toujours la même logique, c'est d'une tristesse sans déconner. Et puis les "pro SX" c'est épuisant aussi, même face à la critique constructive pas moyen d'avoir de débats car soit c'est de la dénigration à la limite de l'insulte, soit les arguments avancés n'ont pas de fondements ou sont développés avec des raccourcis (je ne dis pas que dans l'autre sens ça n'arrive pas non plus mais c'est tout de même plutôt fréquent dans ce sens là).

En premier lieu on a les mercis, normal. Ensuite on a les "Bah alors vous voyez que la TX savent développer", chose que l'on sait déjà et qu'ils n'ont plus à prouver, c'est juste que par exemple SciresM est bien au-dessus d'eux, au moins en terme de hack pur sur cette console et çà aussi c'est plus à prouver. Après on a l'analyse de l'OS qui sort et donc le débat du vol de codes revient alors que là aussi il n'y a plus rien à prouver, la TX utilise du code d'Atmosphere et c'est un fait, là ils n'ont pas utilisé Sept dans leur OS mais à mon avis ils l'ont utilisé pour découvrir les clés permettant de lancer leur OS en firmware 7.0.X, raison pour laquelle il semble y avoir des traces de Sept dans les dernières beta selon moi. Et enfin quand c'est une beta, on a la discussion de qu'est-ce qu'une beta et comment on test les choses avant une release. Après on fait un mixage avec divers questions/réponses d'utilisateurs et on a le flux typiques des commentaires de news SX OS et ces mêmes débats qui reviennent inlassablement alors que rien ne change dans les faits, par exemple si demain SX OS n'utilise plus du tout du code d'Atmosphere alors là se sera l'occasion de relancer le débat mais sinon aucun intérêt, juste on note les choses qui sont toujours utilisées, celles qui ne le sont plus et celles qui sont apparues et on passe à la suite, à moins de prouver que se qui est dit est faux mais là il faut donc évidemment avancer des preuves valables et pas des allégations personnelles sans réel fondement.

Bon là je vois déjà d'avance se qu'on va me répondre, genr "Et l'emunand alors c'est toujours pas inclue à Atmosphere"... et bien je réponds de suite, c'est pas inclue car c'est pas la priorité de ce CFW et que bien évidemment quand on utilise le code des autres bah on a plus de temps pour développer le sien et la TX étant composée de bons développeurs tout de même cela fait la différence. Après niveau étique je ne vais pas encore expliquer la GPL et les conditions d'utilisation du code sous cette licence car je l'ai déjà fait un assez grand nombre de fois.

Pour la version 2.6 beta et ses bugs je trouve que c'était abusé comme bugs, juste l'activation de la licence qui ne fonctionne pas bah là je dirais juste que c'est sans commentaire et pour le bug du disque dur un simple test de deux minutes l'aurait mis en évidence. Alors oui, oublier des choses ça arrive mais bon on a à faire à une équipe de développeurs et pas à un développeur tout seul, ils développent dans un milieu professionnel en étant payés contrairement au milieu de l'open-source dans lequel on développe sur son temps libre (parfois on a une petite donation) et les tests ça prend beaucoup de temps donc les contextes doivent être mis en évidence quand on compare des choses et il est clair que de tel bugs dans une grande entreprise ne seraient pas passés. Après ils ont très vite corrigés le tir cette fois donc tant mieux mais l'excuse de "c'est une beta donc normal qu'il y ait des bugs" je veux bien mais pas des oublis aussi énorme car là c'est plus de l'ordre du bug, c'est clairement une erreur de négligence mais attention, je comprends aussi leur position car ils doivent se faire harceler par les utilisateurs. Ha oui et pour répondre au fait qu'il reste du code de Sept bah c'est probablement des oublis de choses testés pendant le développement, il n'est pas rare d'avoir de tels oublis dans le code, même chez les professionnels.

Pour info j'utilise aussi ce CFW, à la base c'était pour faire des tests mais maintenant je l'utilise aussi pour jouer à mes jeux dumpés car je trouve les XCI plus pratique quand on test souvent des choses et qu'on doit donc faire des restaurations fréquentes de la nand, pas la peine de passer des heures à tout réinstaller, juste les sauvegardes de jeux à sauvegarder puis à restaurer ça prend tout de même beaucoup moins de temps. Pour mes homebrews par contre j'utilise plutôt Atmosphere car les possibilités sont plus ouvertes sur ce CFW à ce niveau là, normal d'ailleurs puisque le but visé est l'optimisation et la personnalisation du firmware, c'est pas le piratage de jeux.

@shadow256
j'ai fait une mise à jour sur le github concernant le script d'initialisation de NSC_Builder.
En effet, on dirait que le chemin du keys.txt a changé.
Tu arrives à récupérer la proposition de modification via github ou ca n'a pas marché ce que j'ai fait ?
Merci

Désolé j'avais pas vu ta pull request, faut dire que je ne vais pas souvent sur la page du projet en ce moment et il va falloir que je configure le projet pour être notifier de ce genre d'évènement. Bref, je t'ai répondu sur le sujet de la requête, c'est un oublie de ma part que je vais corriger dans la prochaine version d'une autre façon mais merci pour m'avoir indiqué ce bug.

PS: La prochaine version va arriver d'ici aujourd'hui ou demain je pense.

je ne suis pas tout a fait d'accord
j'ai pris la rom pal de donkey kong et j'ai appliqué le patch spécifique pour ce jeu du pack "pal to ntsc" et le jeu n'est pas du tout décalé et se lance bien
après j'ai pris la rom pal et je l'aoi ajouté simplement comme ça à hakchi2 et le jeu se lance, car hakchi2 semble patché à la volée les jeux pal en ntsc mais de manière générique sans tenir compte des jeux optimisés 50hz comme donkey ou secret of mana et dans ce cas, oui le jeu est décalé entre la musique et l'image
donc tu peux jouer à donkey pal en ntsc sur l'émulateur intégré sans décalage en prenant le patch spécifique et seulement celui là car il intégré tout (patch ntsc + fix vitesse)

 

Oui, c'est aussi ce que j'ai fais, avec ces utilitaires pour passer en 60Hz :

 

 

Et pour débloquer le Region-free propre à chaque jeu :

 

 

Que l'on soit bien d'accord, les jeux se lancent et le son n'est pas altéré.

 

Mais je te confirme bien que le son reste à la vitesse de 50Hz et la vidéo 60Hz pour chaque jeu que émulé par le Canoe que l'on passe en NTSC ou par le Region-free.

 

En faisant quelques recherches sur ce procédé (50Hz - 60Hz), il s'avère qu'un jeu PAL natif n'est jamais vraiment un jeu NTSC quand il est patché. Hedge Snes que certains d'entre vous doivent connaitre appuyait ce propos dans une de ces dernières vidéos (son podcast sur la SNES mini justement) et il parlait du procédé inverse, quand on passe d'un jeu NTSC en PAL, la musique restait en 60Hz et la vidéo passait en 50Hz, de ce fait, elle avait de l'avance par rapport à l'animé et ça donnait un rendu bizarre qu'il disait (normal du coup). Et c'est exactement la même chose que j'ai constaté, dans notre cas, le passage de 50Hz à 60Hz laisse la musique à une vitesse inférieur à l'animé à l'écran.

 

Pour être plus clair, voici un exemple en comparaison en vidéo que j'ai filmé moi même avec Donkey Kong Country (mais j'aurai pu prendre un autre jeu) :

 

Version avec Retroarch en 50Hz PAL d'origine :

https://www.youtube....h?v=pk-7ziEYeCY

 

Version avec Canoe (émulateur d'origine) avec le Patch Region-free :

https://www.youtube....h?v=5lnk6zGuMQk

 

PS: le son est faible, il faut le monter.

 

Essaie de comparer le moment de la musique quand le rythme s'enchaine avec le thème de Donkey Kong Country, d'origine, lorsque le radio K7 tombe, et avec le patch, lorsque Donkey saute sur Cranky.

 

Pour moi, c'est frappant, cette désynchronisation se voit dans tous les autres jeux où j'ai mis le patch justement, et j'ai essayé de faire de plusieurs manières différentes, j'en arrive toujours au même résultat dés lors que j'applique le patch, et d'ailleurs, ce n'est pas l'émulateur de la SNES mini qui est en cause, j'ai le même problème sur les émulateurs PC, preuve que c'est bien la Rom et le patch qui est en cause.

 

Mais bon, peut-être que je me trompe et que je n'utilise pas le bon patch ?

 

 

Je serai curieux d'avoir aussi l'avis d'autres personnes, je ne pense pas être le seul dans cette constatation... Merci.