jp33

Membres
  • Compteur de contenus

    34 216
  • Inscription

  • Dernière visite

Messages posté(e)s par jp33

  1. oui mais le lock est une spécificité non Microsoft et qui dépend uniquement de l'IDE (c'est pour ça que ça fonctionne si bien et que ce n'est pas contournable simplement).

    Trouves quelqu'un avec un vieux Pc, n'importe quelle bouse est capable de lancer le Linux embarqué sur le CD, même pas besoin de souris (ni de disque dur si le bios accepte de booter sur le lecteur de CD)

  2. mais pour la memory card est ce normale que j ai pas pu mettre les 2 save sur la carte?

    Si c'est Splinter Cell et si ce sont les miennes et si ta carte mémoire n'est pas une originale tu peux avoir des soucis de place, la taille est limite. Pas grave, transfert en deux fois (Par contre il faut les deux sur le disque dur pour que ça fonctionne).

  3. Vous avez vraiment des exemples de consoles qui ont grillées à force d'utiliser une puce ? Ou seulement des exemples de consoles grillées à la tentative d'installation d'une puce ? Parce que c'est complètement différent.

    Et pour être honnête même après des recherches je n'ai pas trouvé une explication hyper clair sur les avantages/inconvénients entre les différentes solutions et qui pourrait justifier un choix évident pour le softmod.

    Donc si vous avez une telle comparaison ça m'intéresse.

    Tchuss

    Il suffit de comprendre le système de la puce qui est juste déplorable sur l'Xbox....

    Elle est juste soudée sur le port de maintenance, trois fois rien. Sauf que pour que ce port soit activé, il faut que le système soit persuadé que la console a un soucis. Quel est le moyen sympathique qu'ont trouvé les fabricants de puce ? Ben un bon vieux court-circuit entre le fameux d0 et la masse. Bref, quand tu appuies sur le bouton marche, ta console se prend une remontée de genoux dans les bijoux de famille. Le temps qu'elle reprenne les esprits, le système à filer la main au port maintenance pour une éventuel intervention du SAV. La puce qui glande depuis le début prend la main, colle son bios dans la mémoire et se rendort, inutile, jusqu'au prochain démarrage. Car une fois le bios en mémoire, plus de sécurités ni contrôles Microsoft.

    Si ce principe te semble "normal", alors croise les doigts car la console fini par griller tôt ou tard... ou jamais, c'est le lot des tolérances sur les composants... Certaines puces "haut de gamme", ont revendiqué un court-circuit "contrôlé", amis bon, à cette époque là, tout était bon pour vendre le plus vite possible. Les soudures sont devenues compliquées sur les 1.6.

    Un flash TSOP est beaucoup plus soft puisque tu remplace le bios directement sur la carte mère. C'est donc un bios non Microsoft qui est lancé. A part les deux soudures pour autoriser le flash du TSOP, c'est sans risque puisqu'elle démarre "normalement". Obligation de passer par un exploit pour lancer le programme de flash, valable uniquement pour le premier, on s'en passe ensuite. Système impossible à utiliser sur une 1.6.

    Avec un exploit, là, c'est uniquement software. Le principe, c'est un démarrage standard (avec logo Microsoft, test du lock du disque dur et de la présence du lecteur de DVD et tout et tout (cette étape peut être sautée avec les deux solutions précédentes)) puis effectue un aiguillage sauvage lors du chargement en mémoire des fonts de caractères du Dashboard d'origine (en gros, le système écrit involontairement un peu trop loin et tu remplaces un pointeur par un autre). Bref aiguillage avec remplacement (comme le cas de la puce) ou patch à la volée (exploit Ndure, procédure tordue permettant de conserver la compatibilité avec le Live même avec un exploit). Là, la console démarre de manière tout à fait standard et s'auto-modifie à chaque démarrage de manière software et uniquement en mémoire (bon, le Ndure peut faire bien plus mais cette partie de l'iceberg est bien suffisante). Seul système fonctionnel quelque soit la version de la console. De plus, concernant le Ndure, c'est le seul système qui a continué à être modifié bien après l'arrêt du développement des puces.

    Bon, pour l'exploit, reste le système d'implantation. La "méthode 007" est 100% safe car 100% software. Le hotswap... ben ça pique un peu pour le disque dur, voir la carte mère, il faut prendre ses précautions et sauvegarder l'eeprom.bin pour remplacer le disque dur en cas de soucis.

    Voilà, maintenant, tu peux choisir, mais il ne s'agit pas d'une légende urbaine... Les puces, c'est MAAAAAALLL !!!!! hihihi

    Surtout quand en plus on ne maîtrise pas la soudure...

  4. mais franchement je suis plutôt adepte du modchip moi...

    Enfin, lorsque les consoles survivent... :fou:

    Même avec un hotswap, tes consoles seraient fonctionnelles... et elle vieilliraient tellement mieux... :whistling:

  5. Concrètement a quoi me servirais ce truc ? Je pourrais flasher directement l'EEPROM avec le x2_5035_v16plus_512k.bin ?

    Regarde un peu plus près où tu le raccordes, tu verras que tu ne touches pas au TSOP... Et puis, flasher le TSOP d'une 1.6, comment dire... ggne

    Par contre, dans la petite mémoire à 8 pattes se trouve une clef (l'eeprom.bin) permettant de calculer un code de lock pour n'importe quel disque dur IDE (ou presque, certains sont récalcitrants).

    Et si ton 160Go est délocké, tu pourras le locker pour la nouvelle (tout en en profitant pour implanter un exploit histoire de ne pas avoir à sortir le jeu méthode 007)

    Accessoirement, il y a belle lurette que le Hotswap fonctionne quelque soit la console... :whistling:

    Indice pour tout ce qui est contenu dans cette réponse: Xcalibur...

  6. Tu ne pourras pas reflasher ta puce depuis un exploit (tu vas essayer de flasher le TSOP... et ce n'est pas simple sur une 1.6), il te faut une deuxième puce.

    essayes quand même avec le 160Go au cas où.

    Pour info, pour la première Xbox, c'était la soudure du d0 qui était malade (en plus de quelques pistes oxydées).

    Sinon hotswap (mais là, il faudra croisé les doigts en espérant que le 160Go n'est pas locké)

  7. ta puce te permettra de lancer un dashboard alternatif qui lancera le DVD d'Xcalibur et sautera l'erreur 05 du à ton nouveau disque dur non locké.

    Donc tu n'as besoin de rien d'autre.

  8. Prépare le disque dur avec Xcalibur sur ton PC, tu peux te passer de l'eeprom.bin (que tu as très peu de chance de trouver sur le disque dur, ça sent le délock avec Evox cette histoire... ). Tu pourras donc oublier volontairement toute la partie concernant le lock du DD.

    Une fois le disque dur de retour dans la console, tu démarres puce activée (tu ne le sauras pas, mais tu auras une console avec exploit le temps de l'installation hihihi ) et dans le menu qui va apparaître, fais une sauvegarde de l'eeprom.bin (parce que ta puce n'a pas la même durée de vie que ta console) puis choisis l'installation pour puce. Cela fera un peu le ménage (parce que là, du coup, avec ta puce, il y a un peu trop de choses inutiles).

  9. Ndure est psychorigide, si tu ne fais pas les choses dans l'ordre et comme il faut, il boude...

    Pour le reste, de mémoire, il me semble qu'Unleash permet d'associer des exécutables ou des raccourcis à une touche appuyée au boot. C'est le fichier de configuration qu'il faut modifier.

  10. Seul les 4 Go du E: sont accessibles, point barre.

    Tout le reste est occupé par le système (je te rappelle qu'à la base, il n'est là que pour les sauvegardes de tes jeux ou tes CD de musiques, à savoir C:, X, Y et Z ce qui fait 4Go au total (tu t'es planté dans la description du C:).... Pas vraiment prévu pour sauvegarder 500 jeux...

    Tu veux de la place ? Tu remplaces ton disque dur par un plus gros épicétou. hihihi

  11. Ndure, par défaut, ne touche à rien et ne modifie rien, ni les xbe, ni les sauvegardes, sur le disque dur.

    Il n'en a pas besoin ou alors il le fait à la volée, en mémoire.

    C'est bon pour les trucs d'amateurs plus anciens (les puces, en particulier ... :whistling: )

    Les copies de sauvegarde, c'est DVD2Xbox, c'est lui qui gère, à toi de choisir les bonnes options...

  12. J'avais affiché 1, 8 Go de libre et j'en ai supprimié 1,1 en plus pour pouvoir installer un jeu de 2Go. Et pourtant toujours que dalle : la xbox se dit trop petite et affiche toujours que j'ai que 1, 799 go de libre on dirait.

    Tu n'as effectivement que 1.8Go de libre. Je ne sais pas où tu as effacé tes 1.1Go, mais ce n'était pas sur le E:. Et comme tu n'as accès qu'au E:...

    X, Y, Z, tu oublies et C: est plein (si, si, c'est étudié pour. De toute façon, c'est inaccessible). F et G, ton DD est un 8Go, ils n'existent donc pas.

  13. Euh...

    Nop, absolument pas! hihihi

    Les puces Xbox1 sont en mode bourrin !! Aucune réflexion à deux balles, juste une remontée de genoux bien placé (un bon vieux court-circuit sur le mondialement connu d0.Comment ça c'est dangereux pour la console ? Ben oui, elle tombe en panne à chaque démarrage, c'est ça l'avantage d'une puce ! ggne ) pour l'envoyer au tapis. Là, en désespoir de cause, le système passe en mode maintenance (en donnant accès au fameux port LPT) et la puce (la fourbe attend tranquillement au bon endroit) en profite pour coller son bios dans l'emplacement mémoire habituel du bios Microsoft (oui, ces gros nazes recopiaient le bios en mémoire au boot) puis fait pointer le proc dessus. Les puces dites "avancées" (X3, SmartX ....) géraient leur propre affichage et permettaient certaines manipulations. Mais le mode de démarrage n'était pas différent d'une homemade...

    Une puce, ça sert 3s en tout et pour tout. Après, c'est 100% logiciel (en gros, le nouveau bios oublie toutes les sécurités M$, le contrôle du lock du DD ou la présence du lecteur de DVD, par exemple ...).