Newserator

teknecal propose une nouvelle version de son homebrew Wii qui, à l'image de la chaine virtuelle de Nintendo , permettra de récupérer les dernières versions de vos homebrews préférés en passant par votre connexion internet , facilitant ainsi grandement leur installation / maintenance ! Nouveautés/corrections : - Ajout d'une fonctionnalité repositories - Refonte de la méthode de montage des périphériques SD/USB afin de tenter de monter au moins un des 2 - Petit nettoyage des différents textes Homebrew Browser 0.3.5 Site officiel : http://wiibrew.org/wiki/Homebrew_Browser Lien vers article original : http://wii.gx-mod.com/modules/news/article.php?storyid=2416

Comme annoncée par Sony lors de la GamesCom 2009, la Playstation 3 a désormais droit à une nouvelle mise à jour de son firmware. Du côté des nouveautés de cette version 3.0, on retiendra notamment : * Divers éléments du XMB (XrossMediaBar) ont été repensés pour une meilleure lisibilité et une utilisation simplifée * accès rapide aux dernières informations sur l'univers Playstation depuis le XMB ([Playstation Network] > [Nouveautés]) * Sortie audio possible via plusieurs connecteurs simultanément ([Paramètres] > [Paramètres son] > [sortie audio multiple]) * Utilisation du stick droit pendant la lecture d'une vidéo (ralenti, retour rapide, avance rapide) * La prise en charge de thèmes animés * Un nouvel affichage de la liste d'amis Source : jeuxvideo.fr Merci à Hoosehot pour l'information. Lien vers article original : http://ps3.gx-mod.com/modules/news/article.php?storyid=1515

<center> </center> Il y a plus de deux mois, nous avons lancé officiellement section complète forum pour une petite console OpenSource, qui n’est nul autre que la Dingoo A320. Dans un premier temps, laissez-nous vous dire que cette section a engendré un grand succès, mais surtout un vif intérêt face à cette petite console, autant vis-à-vis nos membres que plusieurs nouveaux Gueux qui se sont inscrits pour participer au développement ainsi que différentes discussions sur la Dingoo. Voici un bref historique des évènements : Nous avons eu l’apparition de Dingux, l’interface Linux qui a tout changé. Avec l’arrivée de Linux sur Dingoo, c’est ajouter menus, émulateurs, plusieurs ports de jeux destinés à Linux, Gp2X, Gp32, etc.. Plusieurs développeurs y ont vu soudainement un grand potentiel. Pour ce qui est des membres, nous aimerions remercier yoannd26, Ezial, Badablek, Morris ainsi que tous ceux qui ont participé a la rédaction de « news », tutoriel, aide et supports.. Merci! Aujourd’hui, face à ce succès, il est maintenant venu le temps d’ajouter cette petite portable à notre vitrine, mobiles.gx-mod.com pour y présenter l’actualité quotidienne grandissante. Cela n’affecte en rien notre structure forum, c’est simplement une tâche de plus qui s’ajoute à nos rédacteurs Gx-mod! Blague à part, ceci permettra également l'hébergement des différents fichiers, travaux, etc., sur nos serveurs et faire profiter de notre actualité à un plus grand publique. Nous souhaitons ainsi une longue vie à cette nouvelle console, qui est la première console OpenSource à avoir fait l’objets d’actualités sur nos différents sites Gx-mod. Pour plus de détails sur la Dingoo A320, voici quelques liens utiles : - Articles de lancement de la Dingoo sur notre forum - L'actualité complète qui se déroulait sur notre forum jusqu'à aujourd'hui. - Sections Tutoriaux Dingoo. - Guide de démarrage Dingoo A320. Sincèrement vôtre, Team Gx-mod Lien vers article original : http://mobiles.gx-mod.com/modules/news/art...hp?storyid=8898

FrostyTheSnowman propose une nouvelle version de l'équivalent de son disque permettant de gérer le processus de flashage des différents lecteurs, mais cette fois-ci spécifiquement pour les clés USB. Fonctionnalités: - Solution complète de gestion des lecteurs Samsung/BenQ/Lite-On - Firmware iXtreme v1.6 (12x) - Support Samsung TS-H943 - Support BenQ VAD6038 - Support Lite-On DG-16D2S 74850C - Support Lite-On DG-16D2S 83850C - Support des lecteurs déjà modifiés - Support des lecteurs déjà spoofés - Le Dump et le Flashage s'effectue totalement sous DOS - Support FAT32 & NTFS (WinXP/Vista 32-Bit & 64-Bit) - Dump et FLash totalement automatique - Instructions pas à pas - Backup de tous les fichiers relatifs au lecteur sur la cklé USB Nouveautés/corrections de cette v1.60 rev4: - Ajout du support pour les Lite-On DG-16D2S Revision 83850C - Ajout d'un nouveau logo 'FrostyTheSnowman' (merci Shinho!) - Remplacement de FirmTool (par Caster420) par LiteTool (par Klutsh) pour les lecteurs Lite-On - Suppression de DummyGen pour les lecteurs Lite-On (plus nécessaire suite à l'utilisation de LiteTool) - Remplacement de 'USB Drive Format Tool' par 'Bootable USB Drive Creator Tool' (utilitaire créer par Team Modfreakz) - Correction typographique dans le code HTML (merci yaywoop!) - Remplacement de HIMEM.SYS par FDXXMS.SYS (meilleure gestion mémoire) - Mise à jour du tutoriel - Ajout d'une note dans le menu avertissant de ne pas utiliser d'espace dans le nom des dossier à cause de la limitation MS-DOS L'image ISO contenant les firmwares, Gx-Mod ne fournira pas de lien de téléchargement. Nous vous rappelons qu'une version française est disponible pour la version précédente. Source : http://xbins.org Lien vers article original : http://x360.gx-mod.com/modules/news/article.php?storyid=2200

Shakin, membre de notre équipe, propose un mod de Firmware Downgrader (créé par Waninkoko) un utilitaire Wii qui comme son nom l'indique vous permettra de downgrader votre Wii vers n'importe quel firmware disponible sur les serveurs de mise à jour Nintendo. Ce mod propose : - Suppresion du disclamer - Ajout du firmware 4.1 Firmware Downgrader 1.11 modV1 Site officiel : http://wii.gx-mod.com Lien vers article original : http://wii.gx-mod.com/modules/news/article.php?storyid=2415

Suite à l'article concernant l'histoire du hardware Wii, Bushing continue sur sa lancée en revenant sur le problème des fameuses Wii dites LUA64 qui empêchent le lancement de code homebrew. Note : si vous ne l'avez pas encore fait, il est conseillé de lire les articles suivants qui ont été rédigés pour préparer cet article: - L'histoire du hardware Wii - L'histoire de l'IOS Wii Il y a quelques mois maintenant, sont apparus des retours d'utilisateurs à propos de Wii impossibles à modifier de manière logicielle (Wii unsoftmoddable), connues également sous le code "LUA64+". Normalement cela n'aurait pas dû nous intéresser (La Team Twiizers), mais nous avons découvert que notre HackMii Installer ne fonctionnait pas sur ces Wii. Nous avons pensé en 1er lieu que cela provenait d'une modification matérielle inoffensive, coïncident avec le déploiement du boot2v4, mais cela n'a jamais été expliqué. Voici les explications. "LUA64+" est un nom pour le moins idiot afin de décrire ces Wii. Il se réfère aux 4 premiers caractères du N° de série des premières Wii dites unsoftmoddables. Cependant, on ne peut pas blâmer les gens car il s'agit du seul moyen visuel permettant d'identifier ces consoles une fois fabriquées. Retour en arrière au début de 2009. Les éléments suivants concernent toutes les Wii fraichement achetées : 1) Toutes les versions de l'IOS sont désormais corrigées au niveau du bug strncmp(), de l'accès au /dev/flash blocked, et “ES_Identify” ne fonctionne plus. 2) Boot1 voit le bug strncmp() corrigé 3) Des données "poubelles" sont installées dans le slots des IOS3, IOS4 et IOS254 Début mars, un groupe assez bien défini de symptômes lors de lancement de code homebrew ont été observés sur ces nouvelles wii : 1) Les anciennes (mais valides) versions d'IOS ne se lançaient plus, celles-ci bloquaient lors des essais, empêchant ainsi tout downgrade. Cela ne s'appliquait pas à l'IOS16 qui avait été leaké. 2) Les essais de reload d'IOS via libogc provoquaient également de temps à autre des blocages selon le programme. Cela ressemblait à un freeze ou simplement un blocage des appels de l'IOS. Il ne semble exister de différences au niveau software entre une des ces Wii comparé à ce que vous obtiendriez en effectuant une mise à jour via le System Menu. Des personnes proposent des théories telles que "Nintendo a ajouté un code spécial dans le boot1/boot2 permettant la détection de hack, mais ils ont installé une "back door" pour l'IOS16". Comme cela a déjà été expliqué dans le passé, l'exécution de boot1 et boot2 est terminée bien longtemps avant que vous ne voyez quelque chose à l'écran, et n'affectent rien après cela. Bien que boot2 soit responsable du chargement de l'IOS et l'IOS est responsable du chargement du code PowerPC pour le System Menu ou les jeux. Si vous insérez un disque de jeu qui utilise une version différente de l'IOS, l'IOS en cours d'exécution s'occupe de charger et lancer le nouvel IOS, qui lui même lance le code PPC, et peut être éventuellement un autre IOS pour retourner au System Menu, etc... (L'ordre exact de ces étapes devient important pour la suite). Il s'agissait d'une curiosité généralement ignorée puisqu'elle n'affectait pas nos programmes, jusqu'au lancement du HackMii Installer. La raison qui nous a poussé à créer un installer commun pour BootMii, la Chaine Homebrew et DVDx fût qu'il devenait compliqué d'installer des logiciels sur les Wii. Différentes approches ont été nécessaires, selon la configuration des Wii, et on ne pouvait que constater qu'il devenait idiot de multiplier les installers. Cela s'est terminé par la mise en place de codes qui examinent l'état de la Wii sur lequel ceux-ci sont lancés et d'appliquer une stratégie appropriée puis d'installer automatiquement le logiciel souhaité. Il existe plusieurs moyens pour utiliser l'Installer. si cela est possible il utilisera simplement un ancien IOS dont la fonction de comparaison du hash n'est pas patchée et permet un accès illimité à /dev/flash (effectuant un reload vers cet IOS autant que nécessaire). Si ce n'est pas possible, l'Installer choisira un des IOS dans une liste contenant les IOS permettant un exploit selon les versions de l'IOS installé (chaque exploit nécessite d'être personnalisé selon les versions des IOS) et de l'utiliser pour lancer MINI en mémoire et l'exécuter. De là, nous pouvons accéder directement à la NAND flash et détecter la version installée de boot1 et boot2. Au final, cela permet de décider si BootMii peut être installé en tant que boot2, puis retourner à un IOS normal qui permet l'accès à la Wiimote. Bien entendu, le fait de retourner à l'IOS ne se fait pas en un claquement de doigt. MINI contient une fonction qui lance un title spécifique de la NAND via la lecture de boot2 au début de la NAND, puis il patch l'appel de ES_LaunchTitle(1-2) vers le title ID souhaité, et enfin exécute le boot2 patché. Tout ceci s'effectue automatiquement et de manière transparente, mais cela nécessite quelques secondes. A cause d'escrocs qui ont cherché à revendre nos homebrews, nous avons installé un écran d'avertissement anti-escrocs avant de permettre l'installation. Le délai mis en place pour l'installation de l'exploit IOS fait que celui-ci s'exécute durant l'apparition de ce fameux écran d'avertissement. Cela n'a pas fonctionné comme nous le souhaitions sur certaines Wii, étrangement un reboot s'opère au milieu du délai d'affichage de l'écran d'avertissement sur ces fameuses Wii non softmoddables. Soudainement cet état de fait est devenu un problème intéressant. Malheureusement, nous avons tous d'anciennes Wii. Nous étions dans l'incapacité à reproduire le problème nous même. Le seul moyen était d'avoir à la fois une nouvelle Wii et un USBGecko afin d'obtenir des logs de debug. Fort heureusement nous avons fini par mettre la main sur une de ces Wii et de lancer une version debug de notre Installer sur celle-ci. L'Installer a planté lors de la tentative de retour à l'IOS via le boot2. Il s'est avéré que ces nouvelles Wii contenaient une nouvelle version du boot2, boot2v4, et notre routine "patch boot2 pour retourner à l'IOS au lieu du System Menu" ne parvenait pas à trouver le code à patcher. Au lieu d'afficher un message d'erreur, le nouveau boot2 non modifié était exécuté et qui relancer le System Menu en lieu et place de lancer l'Installer. Oops. Cela devait certainement être assez simple à régler. Un patch pour le boot2v4 a été installé et l'Installer semblait réussir à relancer l'IOS, seul un blocage de __IOS_InitializeSubsystems() dans libogc (précisément, ios_open(”/dev/es”)) persistait. Cela commençait à correspondre aux problèmes rapportés au niveau des programmes libogc au moment du IOS_Reload(). svpe a indiqué qu'il avait dû faire face à des problème de délai en travaillant sur le boot avant et après entre les IOS et MINI et a suggéré d'essayer d'ajouter un délai. Lors de l'ajout d'un délai de 5sec dans le code entre le moment ou il est demandé à MINI de recharger l'IOS, et lors de la réinitialisation de ligogc, tout à correctement fonctionné. La situation paraissait étrange puisque le code fonctionnait bien avec boot2v3, puis avec boot2v4 si le System Menu était rechargé (c'est ce qui arrivait aux personnes lorsque le patch boot2 ne fonctionnait pas). Après un ou deux nuits supplémentaires sans dormir, il est devenu clair que boot2v4 prenait plus de temps à charger quelque chose que boot2v3. Si nous vérifions le numéro de version IOS juste avant d'appeler __IOS_InitializeSubsystem(), l'information retournée indiquait la bonne version de l'IOS sur le boot2v3, mais 0 avec le boot2v4. Cela indiquait que le boot2 était toujours actif, boot2 paramètre le numéro de version à 0 lorsqu'il se lance. La réponse à ce problème semblait assez simple, il suffisait d'ajouter une portion de code qui fonctionnerait de la manière suivante : 1) Envoyer IPC à MINI en lui demandant de booter dans l'IOS 2) Retarder le déroulement jusqu'à ce que le numéro de version IOS indique 0 (signifiant que boot2 est entièrement chargé et est en cours d'exécution). 3) Retarder le déroulement jusqu'à ce que la version IOS correspond à la version IOS attendue 4) Lancer l'initialisation de l'IOS Encore une fois, effectuer cette opération provoque une légère différence, mais pas une bonne. Désormais il n'y avait plus de blocage lors de la requête __IOS_InitializeSubsystems(), mais tous nos appels IOS ne fonctionnaient plus dès que nous bootions sur l'Installer, et cela échouait avec des codes erreurs plutôt étranges comme “-900074497?. svpe a alors précisé que le processus de chargement de l'IOS s'effectuait de la manière suivante : 1) lancement de boot2 2) boot2 paramètre le numéro de version de l'IOS à 0 3) boot2 exécute es_main() 4) es_main appelle ES_LaunchTitle(1-2) (ou dans notre cas, IOSxx puisque ce paramètre a été patché) 5) ES_LaunchTitle reconnait que nous tentons de charger un IOS, puis paramètre le numéro de version IOS en mémoire afin que le nouvel IOS chargé sache de quelle version il s'agit. 6) ES_LaunchTitle transfert le contrôle au nouvel IOS 7) IOS se lance et paramètre les registres IPC afin de dialoguer avec le PPC La course fut lancée entre le moment ou ES_LaunchTitle change le numéro de version IOS et quand IPC se lance. si nous tentions de lancer les appels IPC à Starlet avant le changement de numéro de version, c'est comme si nous demandions à IPC d'appeler boot2 alors qu'il était au milieu du reboot. De ce fait nous n'aurions jamais obtenu de réponse et libogc aurait planté. Si nous attendions jusqu'à ce que le numéro de version soit paramétré, libogc tenterait de dialoguer avec le nouvel IOS avant qu'IPc soit initialisé. Dans le cadre de cette initialisation, IOS aurait renvoyé un message "ack" buggé laissant croire à libogc que l'appel ios_open(”/dev/es”) avait échoué et cela n'aurait jamais correctement initialisé ES et tous les appels suivants auraient échoué. Si nous attendions dans notre propre code ce message "ack" (comme suggéré par isobel), alors tout devrait fonctionner. Armés de ces informations, il était devenu possible d'ajouter un bout de code pour ajouter un délai à l'Installer et obtenir les chiffres suivants : Sur le matériel ancien : Temps de chargement boot2v3: 958 ms Temps d'exécution entre boot2v3 et le lancement de l'IOS: Temps d'initialisation IPC: Sur le matériel nouveau: TTemps de chargement: 134 ms Temps d'exécution entre boot2v3 et le lancement de l'IOS: 178 ms Temps d'initialisation IPC: 499 ms Ainsi, nous avions plus ou moins notre solution au problème de boot2v4 et du HackMii Installer, il suffit d'ajouter un certain délai. Alors pourquoi le délai est-il autant différent sur les nouvelles Wii, et pourquoi cela n'affecte pas les opérations habituelles sur la console ? Résumons les faits : * Les Wii récentes sont produites avant un nouveau boot2v4, qui est basé sur le même code présent dans le lot d'IOS publiés en octobre dernier. * Le fait de recharger l'IOS échoue régulièrement sur les nouvelles Wii, spécialement lors d'une tentative de reload d'une ancienne version d'IOS (avant octobre, pris sur une ancienne Wii). * Le lancement de titles PPC fonctionne correctement sur les nouvelles Wii, même si cela nécessite de recharger une version différente de l'IOS (comme cela arrive lors du lancement de la Chaine Homebrew). * Les même versions d'IOS fonctionnent différemment sur les anciennes Wii, et n'ont aucun des problème cités précédemment. La seule différence au niveau logiciels chargés sur ces Wii se trouve dans boot1 et boot2. * La version leakée de l'IOS16 semble exempte de ces problèmes. D'après les recherches précédentes, il est possible d'ajouter les détails suivants à nos connaissances : * boot1 et bc ont chacun 4 révisions, de celles-ci, une était pour corriger le bug strncmp et 3 pour modifier les routines bas-niveau d'initialisation du matériel. * La correction du bug strncmp est apparue en 1er dans l'IOS37 en Mars 2008. IOS, bc et boot1 ont apparemment été corrigés en internet par Nintendo / BroadOn en Février/Mars 2008 mais n'ont pas été publiés avant plusieurs mois après cette correction. * bc (et probablement boot1) a été revu avec quelques modifications mineures au niveau de l'initialisation matérielle. * Les nouvelles versions de boot2 et de tous les IOS ont été réalisées le 11 juillet 2008 * Les nouvelles versions IOS ont été placées sur les serveurs de mise à jour Nintendo en Octobre * Les Wii ont commencé à être vendues avec les nouveaux IOS (mais avec boot2v4) fin 2008 * Deux révisions du PCB ont été réalisées à la fin 2008, début 2009, toutes ces Wii ont été vendues avec les nouveaux IOS et boot2v4, et ne semblent pas fonctionner très bien avec les anciennes versions d'IOS. * L'unique modification remarquée sur le PCB se situe au niveau du circuit d'alimentation. Hollywood (où l'IOS est exécuté) n'a pas été modifié (toujours en version "Hollywood AA") et quelques modifications mineures et sans conséquences ont été faites sur le Broadway. Un scénario commence à émerger : 1) Nintendo développe un nouveau design des PCB pour réduire les coûts en simplifiant le circuit d'alimentation mi-2008. Le nouveau PCB contient moins de composants mais demande quelques millisecondes supplémentaires pour stabiliser le voltage de l'alimentation. 2) Le nouveau matériel nécessite un kernel IOS plus tolérant, de ce fait BroadOn revoit boot2 et IOS afin que Nintendo les utilise sur le nouveau PCB. Ces version IOS restent toutefois compatibles avec la révision C/RVL-CPU-01. 3) Nintendo publie les nouveau IOS via une mise à jour fin 2008, pour annihiler le bug strncmp() (ainsi que l'accès /dev/flash et ES_Identify() 4) Nintendo lance la production du PCB C/RVL-CPU-01 avec les nouveaux IOS sur celui-ci (boot2 n'est pas mis à jour, Nintendo n'ayant aucun intérêt à le faire). 5) Nintendo lance éventuellement une production massive de PCB C/RVL-CPU-20 qui nécessitent un boot2(v4) mis à jour afin de fonctionner, ainsi que de nouvelles versions IOS qui ont déjà été correctement testés à ce moment là. 6) Les clients reçoivent ces nouvelles Wii basées sur le C/RVL-CPU-20. Certains tentent d'installer d'anciennes versions IOS et de lancer du code libogc utilisant ces IOS. 7) libogc ne sachant pas qu'il est désormais nécessaire d'attendre un peu plus longtemps pour recharger IOS, et selon le délai, provoque un blocage ou empêche l'initialisation de l'IOS. Il est fort probable que Nintendo n'a jamais imaginé que cela pouvait être un problème. Voici comment le système boot normalement : 1) Mise sous tension du système 2) boot / boot1 / boot2 se lancent sur le Starlet 3) boot2 charge le TMD pour le System Menu, regarde la version IOS nécessaire, puis lie le chargement à cette version de l'IOS 4) La nouvelle version chargée de l'IOS charge le System Menu depuis la NAND vers la mémoire, puis active le PPC et l'exécute. 5) L'utilisateur sélectionne une chaine ou un disque, IOS charge TMD, et se relance dans le nouvel IOS 6) IOs lance le jeu depuis la NAND ou le disque vers la RAM, puis bootstraps PPC Voici ce qui arrive lorsque quelqu'un lance un USB loader depuis la Chaine Homebrew : 1) L'utilisateur sélectionne HBC depuis le System Menu, le menu appelle ES_LaunchTitle(00010000-HAXX) 2) IOS regarde le TMD HBC depuis la NAND, observe que l'IOS61 est nécessaire (ou autre) et se recharge avec celui-ci. 3) IOS61 initialise le hardware, puis charge le contenu HBC dans la RAM et boostraps PPC 4) L'utilisateur sélectionne son USB Loader depuis la SD Card 5) HBC lance le ELF depuis la SD Card dans le PPC et va vers ce dernier directement 6) L'ELF appelle (par exemple) IOS_Reload(249) pour charger une version patchée de l'IOS 7) Libogc effectue un appel IPC vers l'IOS pour recharger l'IOS, mais n'attends pas assez longtemps pour que le processus se termine et tout se confond. Dans le scénario normal de Nintendo, IOS est toujours celui se rechargeant lui-même puis la nouvelle version de l'IOS charge le PPC et lance le code. Il n'y a jamais aucun code PPC s'exécutant durant ce processus , et le code PPC est impossible à lancer tant que l'ARM n'est pas prêt. A contrario, le processus utilisé par libogc se réalise "en coulisses", avec le PPC rechargeant le code ARM, un code de synchronisation insuffisante est utilisé pour éviter cette course car les anciennes Wii se rechargent tellement vite que ce fait n'a jamais été un problème. Voici ce qui arrive lorsque quelqu'un lance (par exemple) un forwarder de chaine depuis le System Menu, une bannière avec un TMD leurre qui charge une ancienne version (probablement patchée) d'IOS puis lance autre chose : 1) L'utilisateur sélectionne "forwarder channel" depuis le System Menu, le menu appelle ES_LaunchTitle() sur le title 2) IOS regarde le TMD de la chaine depuis la NAND, observe qu'il nécessite IOS36 (ou autre) et se recharge avec celui-ci. 3) IOS36 ne parvient pas à initialiser correctement le hardware et le système se bloque. Ce n'est pas une explication absolue. Pour le moment on ne peut expliquer : * Pourquoi l'IOS16 continue de fonctionner * Quelles fonctions spécifiques sont nécessaires dans un IOS pour qu'il fonctionne sur les nouvelles Wii. Le processus de boot d'un IOS est multithreadé et difficile à suivre. * Pourquoi, précisément, le nouveau code est nécessaire * Pourquoi la dernière version du HackMii Installer ne fonctionne pas sur toutes les Wii avec boot2v4, même si le code de synchronisation est en place Quoi qu'il en soit, il s'agit surement des meilleures explications possibles plutôt qu'un "Nintendo a mis en place un truc magique pour faire des Wii non softmoddables". Ne vous méprenez pas, il est certain que des sourires sont surement apparus chez Nintendo lorsqu'ils ont vu que ce hack ne fonctionnait plus. Mais habituellement les efforts de Nintendo contre les hackers sont moins subtils, par exemple, en bloquant le /dev/flash et corrigeant l'exploit IOS utilisé auparavant dans l'installer HBC. Si vous, lecteur, souhaitez vous amuser avec cela, voici un petit programme de test dont vous pouvez télécharger les sources et le binaire. Il s'agit principalement d'une version du code libogc IOS_Reload, mais affichant des informations de debug sur l'écran de votre TV et quelque code de délai. Ce n'est pas exactement le même dont il fût question plus haut dans cet article, boot2 n'est pas invoqué dans ce processus, mais ceux d'entre vous qui ont accès à ces nouvelles Wii avec un boot2v4 (et pour ceux dont l'installer HackMii ne fonctionne pas) peuvent participer à trouver ce qui ne va pas. Vous pouvez librement changer les 2 version d'IOS ("from" (depuis) et "to" (vers). Lorsque ce code est lancé sur une Wii Coréenne, les chiffres suivants sont affichés : stats: id=0x06bcc32d boot2v3 IOS46->IOS22 IOSticks=32 IPCticks=475 stats: id=0x06bcc32d boot2v3 IOS46->IOS20 IOSticks=32 IPCticks=1041 Sur une ancienne Wii NTSC (qui était distribué à l'origine avec un boot2v2) : stats: id=0x0408cafa boot2v3 IOS35->IOS22 IOSticks=32 IPCticks=497 stats: id=0x0408cafa boot2v3 IOS35->IOS20 IOSticks=32 IPCticks=1052 Il peut être intéressant de voir si des différences substantielles apparaissent selon le type de matériel. Site officiel : HackMii Lien vers article original : http://wii.gx-mod.com/modules/news/article.php?storyid=2414

dimok publie une nouvelle version de test de son projet nommé WiiXplorer. Utilisant LibwiiGui ce programme propose de nombreuses fonctionnalité et un design soigné (réalisé par NeoRame). Fonctionnalités: - Copie/déplacement/effacement de fichiers/dossiers présent sur SMB/USB/SD. - Possibilité de renommer les fichiers - Informations sur les fichiers/dossiers - Exploration SD/USB/SMB - Barre d'adresse avec le chemin - Boot des fichiers .dol/.elf via un double clic - Nouveau style/images par NeoRame - Support des fichiers TXT/PNG/JPEG/MP3/OGG Nouveautés/corrections : - Support Multilangues - Support des fichiers XML et GIF WiiXplorer 0.1 Pre Alpha r35 Site officiel : http://code.google.com/p/wiixplorer/ Lien vers article original : http://wii.gx-mod.com/modules/news/article.php?storyid=2413

Erik Spyder propose une petit utilitaire PC qui vous permettra d'obtenir le TITLE ID d'un ou plusieurs fichiers WAD. Instruction: Glisser et déplacer un fichier / répertoire vers la grille. WADInformer 1.0 Lien vers article original : http://wii.gx-mod.com/modules/news/article.php?storyid=2412

Slappy publie une nouvelle version de son portage du jeu Quadrax IV qui a été développé à l'origine pour ZX-Spectrum en 1994 par la société slovaque Cauldron.Le jeu va mettre à l'épreuve la rapidité de vos doigts et votre matère grise à travers 90 niveaux. Nouveautés/corrections : - usage de la mémoire moins important - Possibilité de prendre des captures d'écran (Nunchuk bouton C). Les screenshots sont sauvegardés dans apps/quadrax/screenshots en tant que fichiers .bmp. - Ajout du niveau dans le HUD - Le nombre maximum de niveau débloqués n'est pas toujours sauvegardé correctement (si cela arrive merci de contacter l'auteur par email) - Ajout de mouvements de camera (Nunchuk joystick) Le jeu utilise la Wiimote et le Nunchuk en lieu et place du clavier et de la souris pour la version originale. Vous pouvez jouer à un ou deux joueurs uniquement sur la même console. Quadrax IV 0.3 Site officiel : http://wiibrew.org/wiki/Quadrax Source : Tehskeen Lien vers article original : http://wii.gx-mod.com/modules/news/article.php?storyid=2411

Alekmaul sort un émulateur PC Engine portant le nom de DOOEngine. Pour l'instant l'émulateur est seulement en version BETA. Il est compatible avec l'OS d'origine de la Dingoo et non avec dingux. Il vous suffit de copier le fichier DOOEngine.SIM da&ns votre dossier GAME et d'ajouter vos fichiers .PCE ou vous souhaitez. DOOEngine V09b Site officiel : http://www.portabledev.com/pages/dingoo/jeuxdev.-perso/dooengine.php Lien vers article original : http://mobiles.gx-mod.com/modules/news/art...hp?storyid=8897

Cela faisait un petit moment que Bushing de la Team Twiizers ne s'était pas fendu d'un article, comme toujours fort intéressant, concernant certains aspects techniques de la Wii. Aujourd'hui Bushing a publié un article concernant l'histoire des révisions matérielles de la console de Nintendo dont nous vous proposons la traduction. Les fabricants de matériel électronique ont pour habitude de constamment revoir le modèle de fabrication de leur produit durant le temps de vie et cela, généralement, pour 4 raisons: 1. Amélioration du rendement : afin de corriger les problèmes provoquant des retour en garantie 2. Réduction des coûts : en utilisant des composant moins chers ou moins nombreux afin d'augmenter les marges ou de baisser le prix de vente (ou les deux) 3. Mise à jour des composants — quelques fois les fabricants arrêtent de produite certains composants (par exemple les puces mémoires de 64MB), de ce fait ils commencent à utiliser de "meilleures" puces car ce sont les seules désormais disponibles. 4. Sécurité — modifications anti-modchip Beaucoup de personnes pensent uniquement à la dernière raison, mais les 3 premières sont en fait plus courante. Sony a surement été un des plus actifs dans la révision de ces modèles. N'ont-ils pas réalisé quelque chose comme plus de 30 révisions de la PS1, plus de 15 pour la PS2, et de nombreuses pour la PSP et PS3 ? Microsoft a réalisé 5 ou 6 révisions de sa Xbox 1 et 3 de la Xbox 360. Nintendo quand à lui en a très peu surement car ils n'ont jamais vendu leur console à perte, de ce fait ils ont moins de raisons de se lancer dans la révision du processus de fabrication. Il faut savoir qu'en général cela côute très cher de revoir le PCB et de modifier le processus de fabrication pour en faire un nouveau, sans oublier le risque de créer de nouveaux problèmes matériel et d'augmenter le taux de panne)) Revenons à notre Wii, nous pouvons considérer les choses suivantes qui sont plus ou moins indépendantes: - Les mises à jour du lecteur disque - Les mises à jour des "grosses puces" (Hollywood, Broadway) - Les mises à jour du PCB principal Nous avons pu assister à de nombreuses mises à jour du lecteur disque, elles sont d'ailleurs bien connues! De mémoire il y a eu DMS/D2A, D2B (identique au D2A, mais avec un changement du masque de la ROM d'une des puces — probablement pour la raison #1), D2B avec des pistes coupées (raison #4), D2C (raison #4), D2C2 (raison #4), D2E (inconnue — raison #1?), D2E + epoxy (raison #4), “D2nothing” (peut etre raison #2, mais surement plus pour la raison #4). Il est clair que Nintendo a surtout été motivé a réalisé ces mises à jour pour des raisons anti pirates. Nous avons également vu quelques révisions au niveau des puces Broadway et Hollywood. La plus vieille photo de ces puces qui a pu être trouvée en ligne date du 17 novembre 2006: Notez qu'il s'agit de la 1ére révision de chacune des ces puces - appelées simplement “Broadway” et “Hollywood”. D'après la photo on peut dire que la puce Hollywood a été fabriquée la 32ème semaine de 2006 (”0632″) et la puce Broadway a été fabriquée la 31ème semaine (”0631″). Malheureusement il n'y a pas beaucoup de gens qui partagent la même et étrange fascination que moi de prendre des photos de l'intérieur de leur console, de ce fait il est assez difficile de trouver des photos proposant un large éventails des puces. Sur la Wii coréenne que j'ai acheté, celle-ci avait un “Hollywood AA” (date code 0812) et un “Broadway B” (0744). Il est fort probable qu'un “Hollywood A” a existé, si quelqu'un en possède un, merci de bien vouloir envoyer une photo ou au moins indiquer le date code afin de compléter le schéma de production selon les dates. (J'ai également un “Hollywood AA” (0801) avec un “Broadway A” (0747)), et un “Hollywood” (0636) avec un “Broadway A” (0641)). Les différences entre les révisions de puces ne sont pas très explicites pour nous. Toutes les puces doivent lancer le même code. Il s'agit plus pour les révisions de puces de corriger des bugs mineurs. Par exemple, il existe plusieurs emplacements dans l'IOS pour vérifier si la puce Hollywood est plus ancienne que certaines versions, et si c'est le cas, l'exécution de code additionnel est lancée (écritures mémoire redondantes, probablement pour contourner un bug dans le silicone). Plus intéressant cependant, ce sont les modifications au niveau du PCB. Les 1éres années ont vu un seul PCB pour la Wii, le “C/RVL-CPU-01″; mais durant l'année passée, il semble que 2 nouvelles révisions ont vu le jour (-20 et -30, comme visible ci-dessous): C/RVL-CPU-01 vs -20 vs -30 Notez que les différences majeures entre les révisions -01 et -20 concernent la suppression de certains composants. Segher pense qu'il s'agit d'une simplification du circuit d'alimentation, ce qui aura son importance plus tard. En supprimant une partie des composants cela a surement permis à Nintendo de gagner quelques dollars de plus. Il est important de noter que ni la puce Hollywood ni la puce Broadway ne semblent avoir changé. Il s'agit toujours d'un Hollywood AA et d'un Broadway B. Le PCB -30 est intéresssant. Cette photo provient d'une personne sur IRC qui a acheté une nouvelle (”non softmoddable”) Wii en Australie. Il m'a envoyé cette photo afin de nous aider à débugger HackMii Installer. La seule différence entre ces versions concerne l'enveloppe du Broadway qui est beaucoup, beaucoup plus petite. Ma théorie concernant les révisions de PCB est que le passage du PCB -01 au -20 coïncide avec le passage du boot2v3 au boot2v4, et c'est là qu'ont commencé à apparaitre les fameuses Wii "non softmoddable". Cet aspect software fera l'objet d'un autre article. Site officiel : HackMii Lien vers article original : http://wii.gx-mod.com/modules/news/article.php?storyid=2410

Darkyesus sort la version 3.0 de son navigateur à la sauce Windows XP pour Nintendo DS nommé WintenDoS. Citation : Plus de 1 an sans mise à jour, WintenDoS revient en version 3.0! Avec un moteur repris à zéro, un système de gestion de fenêtres, une architecture de fichiers FAT... bref, un retour foudroyant! En contrepartie, toutes les applications ont disparut, mais elle reviendront bientot, avec encore plus de fonctionnalités en prime! Notez que nous participons aux compos NeoFlash summer 2009, SceneryBeta 2009 et R4 compo 2009. Nous vous invitons à aller voter (en nôtre faveur bienur ^^' )! WintenDoS v3.0 Site officiel : http://wintendos.olympe-network.com/Telechargement.php Lien vers article original : http://mobiles.gx-mod.com/modules/news/art...hp?storyid=8896

Voici un test d'une puce un peu spéciale qui a pour particularité de ne pas lancer de backups ou d'ajouter des fonctions liées au hack d'une console. La PulseVU2 fonctionne sur n'importe quelle console voir même n'importe quel appareil disposant de LEDs. Son but, apporter une touche techno aux petites lumières de vos appareils, et pour ce test nous l'avons utilisée sur une Wii. Si l'envie vous prend de donner une touche artistique à votre Wii une fois les lumières éteintes, ce test est fait pour vous. Site officiel : Accéder au test de la PulseVU 2 sur Wii Merci à Shakin pour le test (et à Mikael0769 pour la transcription wiki) ainsi que notre partenaire Magichip pour le produit. Lien vers article original : http://wii.gx-mod.com/modules/news/article.php?storyid=2409

Il semble que des gens en chine aient mis la main sur une PSPGo et qu’ils aient décidé de lui ouvrir les entrailles afin que nous puissions découvrir le niveau hardware de la prochaine PlayStation Portable de Sony. Ci-dessous vous trouverez certaines informations provenant de leur site. Ici nous parlons d’une carte-mère TA-091, les connaisseurs PSP savent de quoi il s’agit. À première vue, il n’y a pas de câble UMD Nous ne savons pas si cela est positif ou non, si c’est un pas en avant ou un pas en arrière, le système de touches est intégré à la carte mère cette fois-ci, un peu comme une structure de téléphone cellulaire. Cette structure a l’avantage de procurer une meilleure durée de vie, mais une fois endommagée, il faudra probablement remplacer la carte-mère elle-même. Tout comme un clavier à touche en silicone, la vitesse de réaction lors de la saisie de touche devrait être quelque peu, sinon clairement diminuée. On remarque également ici le support de carte M2 « MemoryStick Micro », qui est beaucoup plus dispendieux pour Sony. Les anciennes PSP proposaient le support MemoryStick Pro Duo d’une capacité plafonnée à 16Go et pour le M2 propose une capacité actuellement plafonnée à 8Go. Cependant, les deux formats sont voués à une capacité de 32Go dans le futur. Mais ceci demandera probablement une mise à jour système de la part de Sony, si cette capacité augmente un jour bien entendu. Juste à côté nous voyons le module de connexion WiFi, cependant ce module nous ne permet pas de vous apporter plus de détails (si vous avez de l’information pertinente, contactez-nous via notre forum). Ici on aperçoit le clavier de contrôle dont on a fait mention plus haut. Ensuite, à gauche nous avons le commutateur sans-fil qui contrôle le Bluetouth et WiFi. Le chiffre au bas de la carte mère est une partie intégrante de la prise « jack » en métal. Elle intègre; contrôle, sortie vidéo, charge, etc.. Et nous souhaitons bien sûr que ces joints résisteront aux insertions et retraits répétés. On remarque également le micro sur la gauche, qui sans lui, la téléphonie sur Internet serait impossible. Et pour terminer, on aperçoit la prise de connexion de l’écran qui ne nous apporte aucune information supplémentaire pour le moment. Merci à Niconico27 pour la source. Source : Levelup.cn Lien vers article original : http://mobiles.gx-mod.com/modules/news/art...hp?storyid=8895

Un problème majeur résolu : l'obtention du CD.1921.bin . On ne pouvait pas l'obtenir légalement dans sa forme décryptée. Cela a été résolu en désassemblant le CD.1920 et en appliquant des changements du CB.1920 vers CB.1921. Tmbinc ne pouvant poster le code source assembleur (code MS), il a construit un script qui permet de changer un CD.1920 en CD.1921. Il faut donc : un CD.1920 un CD.1921 Le script : http://free60.git.sourceforge.net/git/gitw...d/1920to1921.py . Fonctionne sur les CD des Xenon, Zephyr et Falcon, mais pas sur Jasper. Cela permettra de créer une image avec le CD 1921. Attention, le build.py actuel nécessite le code SMS mis à jour pour lire 0x200 au lieu de 0xffc000. Vous pouvez patcher le fichier à la fin du code SMS, cherchez "ea 00 c0 0f 00 xx yy zz", et corrigez xxyyzz=0x200 (au lieu de 0xffc000). Procédure : Renommer CD.1920.bin en CD.1920, poser le fichier dans un sous dossier input Renommer CB.1921.bin en CD.1921, poser le fichier dans un sous dossier input python 1920to1921.py 1921 Merci à Bono2007 pour l'information Lien vers article original : http://x360.gx-mod.com/modules/news/article.php?storyid=2199

timbrug propose une mise à jour de son portage de cet émulateur MSX sur Nintendo Wii. Basé sur la dernière version de BlueMSX (2.8.2), il supporte désormais complétement les manettes Gamecube et divers bugs sont corrigés, notamment concernant les sauvegardes. BlueMSX 1.0 Site officiel : http://code.google.com/p/bluemsx-wii/ Lien vers article original : http://wii.gx-mod.com/modules/news/article.php?storyid=2408

Le responsable de la production de la Xbox 360, Aaron Greenberg, a révélé à Gamespot que les désastreux RROD (Red Ring Of Death) et les erreurs E74 appartenaient désormais au passé. "Nous avons travaillé dur pour effectuer des améliorations sur les consoles que nous produisons actuellement, je pense que tout ceci est bien derrière nous" a-t-il déclaré. Il a ajouté que les améliorations technologiques avaient grandement amélioré la stabilité. "Je peux vous dire que les consoles que nous produisons aujourd'hui bénéficient de pièces bien moins calorifiques et d'une meilleur aération; leur qualité est aujourd'hui fantastique" a-t-il ajouté. "Cela dit, je connais des gens qui ont acheté leur console assez tôt dans le cycle de vie de la console et c'est la raison pour laquelle nous avons étendu la garantie à tous ceux qui subiraient les RROD et les E74." Source : EreNumerique.fr Lien vers article original : http://x360.gx-mod.com/modules/news/article.php?storyid=2198

Elle ne sortira que le premier septembre prochain, mais elle est d’ores et déjà listée chez certains revendeurs français. Elle, c’est bien sûr la nouvelle PS3 Slim de Sony qui se distingue par ses dimensions revues à la baisse, mais aussi et surtout par son nouveau prix de 299€ qui fait d’elle une plateforme multimédia plutôt attractive quand on voit le prix d’un simple lecteur Blu-Ray. Pour l’instant, seul CDiscount affiche la console comme étant en stock, mais vous pouvez d’ores et déjà précommander la PS3 Slim chez la majorité des enseignes qui la mentionne dans leur catalogue. Source : Revioo.com Lien vers article original : http://ps3.gx-mod.com/modules/news/article.php?storyid=1514

Le site Amazon.de a semble t-il laissé échapper une information concernant l'arrivée d'un nouveau pack Elite pour le mois d'octobre. En effet, on pouvait voir sur le site allemande du groupa Amazon un pack Elite composé de : - Console Elite 250 GB - 2 Pads sans fils - Et le jeu Forza Motorsport 3 Ce pack proposé à 279.99€ doit être disponible courant octobre. A l'heure actuelle la page de l'article à purement et simplement disparue (le site Engadget a eu le temps de faire une capture d'écran). Merci à Burning_Out pour l'information Lien vers article original : http://x360.gx-mod.com/modules/news/article.php?storyid=2197

Un autre mod de l’excellent moteur Open Beats Of Rage vient d’être releasé par NickyP, Maplevania! Vous l’aurez sans doute compris, il s’agit d’un croisement entre Maplestory et Castlevania. Vous pouvez choisir entre trois personnages, Ethan Belmont, Claus Moriarti, ou Amelia Delacroix et ainsi combattre toute la vermine qui se trouve sous votre passage! Note : Le pack comprend le BOR Pak ainsi que le moteur (pack prêt à l'emploi) Maplevania - OpenBOR Source : Qj.net Lien vers article original : http://mobiles.gx-mod.com/modules/news/art...hp?storyid=8894

Microsoft officialise la baisse de prix aux USA de la Xbox 360, qui n'était plus qu'un secret de polichinelle. Cette baisse de prix interviendra dès demain : - Xbox 360 Elite $399.99 -> $299.99 - Xbox 360 Pro $299.99 -> $249.99 Jusqu'à épuisement des stocks - Xbox 360 Arcade $199.99 -> $199.99 Pour la France selon les dernières informations, la baisse de prix du pack Elite pourrait également intervenir dès demain avec un passage de 299€ à 249€ et le lancement d'un pack Arcade contenant le jeu Banjo-Kazooie : Nuts and Bolts au prix de 199€. On attendra cependant le communiqué officiel de Microsoft concernant la baisse de prix pour la France. Lien vers article original : http://x360.gx-mod.com/modules/news/article.php?storyid=2196

Ce nouveau lecteur qui porte la référence D3-2 et qui ressemble au lecteurs D3, à la différence près qu'aucune solution de hack (modchip ou softmods) connue à ce jour ne semble fonctionner, a fait l'objet d'un test par un dénommé fasman. Le test consiste à utiliser une puce Sunkey et de voir comment réagit le lecteur face à différents types de support : Source : Wiinewz Lien vers article original : http://wii.gx-mod.com/modules/news/article.php?storyid=2406

StrmnNrmn et son équipe nous apportent une nouvelle mise à jour de DaedalusX64, l’émulateur Nintendo64pour PSP. Pour rappel, DaedalusX64 est une continuité du projet original Daedalus PSP qui a été porté par StrmnNrmn et plusieurs autres développeurs. Nouveautés et corrections : - Ajout d’un avertissement de charge de batterie à bas niveau. L’option peut être activée dans Global Settings. - Ajout du format correct de sauvegarde pour Fighter’s Destiny 2 (il boot maintenant). - Ajout de 13 jeux dans la liste de compatibilité qui utilise l’affiche double (DoubleDisplay). - L3DEX se nomme F3DEX pour le moment… - Correction du sol dans Fighting Force 64. Liste de compatibilité officielle : http://daedalusx64.com/compat/ DaedalusX64 Alpha Rev429 Site officiel : http://daedalusx64.com/ Lien vers article original : http://mobiles.gx-mod.com/modules/news/art...hp?storyid=8893

Yoshihiro nous apporte une nouvelle version de son émulateur Nintendo DS pour PSP, il passe donc en Beta 3. Pour rappel, Yoshihiro travail d'arrache-pied afin d’adapter l’émulateur DeSmume sur PSP. Nouveautés et corrections : - Mise à jour GPU, MMU, MMA, RTC et plusieurs autres améliorations. - Amélioration de la vitesse dans DBZ2 à 15fps, sur l’ancienne version il roulait à 7fps. - Mise à jour du core Gfx3D de DeSmume core 9.4. - Ajout debug information, de cette façon vous pouvez consulter vos résultats lors de jeux qui freeze. - Retrait du CPU Ratio Hack. Utilisation : Placez le contenu de l’archive à la racine de votre memory stick et placez vos roms *.nds dans le dossier ndsrom dans le dossier de l’eboot.pbp. Pour connaître les contrôles, consultez le fichier readme inclus dans l’archive. DSonPSP beta3 - par yoshihiro Source : PS-World Lien vers article original : http://mobiles.gx-mod.com/modules/news/art...hp?storyid=8892

Pour parvenir à produire la PS3 Slim, Sony a forcément revu sa copie en matière d'agencement de la console. A peine sortie que le site Ifixit a déjà mis en pièce la nouvelle PS3 et vous propose d'en découvrir les entrailles. Site officiel : Accédez au démontage de la PS3 Slim Source : Gameblog Lien vers article original : http://ps3.gx-mod.com/modules/news/article.php?storyid=1513