Après quatre ans de travail, le bidouilleur canadien DiscoStarslayer a annoncé que son firmware du MechaCon était enfin sorti ! Si vous ne connaissez pas le MechaCon, c'est la puce de sécurité que Sony avait posée en 1999 dans les premières PlayStation 2, et c'était encore jusqu'à aujourd'hui, l'un des derniers composants de la console dont personne n'avait pu obtenir le code...

Ce MechaCon tire son nom de la mécanique qu'il surveille, à savoir le lecteur optique et la mémoire flash, sauf que ces petits malins de Sony lui ont confié bien plus que ça... En effet, cette bestiole sais déchiffrer les cartes mémoire MagicGate, et surtout c'est elle qui décide si le disque que vous venez d'insérer est authentique ou pas. Donc une PS2 dont le MechaCon est raide mort, ça devient une jolie brique

La puce, soudée sur une carte mère Sony de 1999 ( Source )

Pour aller lire dedans, il a fallu y aller à la manière forte... La puce a donc été ouverte chimiquement pour mettre le silicium à nu, puis lue au microscope. C'est une opération délicate qui consiste à recopier optiquement le contenu de la ROM directement depuis le circuit. C'est lent, et c'est source d'erreur, mais ces dumps crasseux n'étaient pas le but, mais plutôt le moyen... En effet, Libby, un autre hacker qui a collaboré au projet, y a trouvé une faille exploitable, et c'est cette faille qui a ensuite permis de sortir le contenu de la puce via logiciel.

Comme ça, plus besoin de sacrifier une console pour en lire une.

Le firmware extrait, ouvert dans un éditeur hexadécimal : les chaînes laissées par le développeur Sony sont encore dedans ( Source )

Après attention, il s'agit pour le moment uniquement du premier MechaCon, c'est à dire de celui des PS2 d'avant les SCPH-500xx. Celui des modèles suivants, un ARM que Sony avait baptisé Dragon, était déjà tombé au combat, et c'est de ce dump-là qu'était sorti par la suite l'exploit MechaPwn . Donc ni les Slim ni les dernières Fat ne sont concernées ici par ce nouvel exploit.

Alors qu'est-ce que ça débloque ?

TechPowerUp écrit qu'il y a de bonnes chances que ça finisse par permettre un vrai émulateur de lecteur optique, un de ces boîtiers qui remplacent le bloc optique par une carte SD, ce que les fans réclament depuis des années. Sauf qu'un des développeurs qui ont participé au reverse est allé démentir ça sur Hacker News : les dumps seuls ne donnent pas assez d'informations pour fabriquer un tel boîtier. En effet, il manque de quoi rejouer le dialogue côté lecteur, et c'était justement ça la partie difficile.

Après pour lancer des copies de jeux non plus, il n'y a rien de neuf là-dedans puisqu'on les lance déjà depuis une carte mémoire, un disque dur ou l'exploit du lecteur DVD. Ce qui devient envisageable par contre, c'est une puce qui prendrait la place du MechaCon en laissant le processeur de signal de la console continuer à lire les disques. Autrement dit, une console que son MechaCon a brické pourrait être réparée au lieu de finir à la poubelle.

Et ça, je trouve que c'est plutôt une bonne nouvelle même si la méthode d'extraction écrit énormément dans la NVRAM de la console, et ça use le matériel.

Ahet il n'y a pas que des consoles de salon dans l'affaire puisqu'on retrouve également le MechaCon dans des cartes d'arcade à base de PS2, dont les Namco System 246 et System 256.

Quoiqu'il en soit, ces dumps serviront aussi à l'émulation, parce que toute la sécurité des cartes mémoire et des exécutables signés passe par cette puce. Ça devrait être bien utile !

Source : Hardware Busters et TechPowerUp .

L'équipe derrière suyu , l'émulateur Nintendo Switch né des cendres de yuzu , a publié le début septembre une dernière version de son logiciel, puis a fermé le dépôt sur un ultime commit intitulé "FINAL". Et cette version d'adieu embarque un truc que j'ai trouvé intéressant. C'est un mode baptisé Recompiler, qui change totalement la façon dont le code du jeu est "traduit".

D'habitude, un émulateur traduit les instructions ARM de la console en instructions x86 au fur et à mesure que le jeu tourne. C'est ce qu'on appelle un JIT. Alors que là, le mode Recompiler fait le boulot à l'avance en prenant le code ARM64 du jeu et en le convertissant en code C.

Le code de suyu ne cache pas d'où vient l'idée, puisqu'il se décrit lui-même comme un moteur produisant du C portable "à la manière de N64Recomp". Grâce à cette technique de recompilation, en bout de la chaîne, vous obtenez un vrai binaire .exe sous Windows, ELF sous Linux, ou Mach-O sous macOS.

Faut savoir qu'un jeu entier, ça fait des millions de blocs de code (oui, des millions !), et réunis dans un seul fichier C, ça pèserait des centaines de mégaoctets. Soit de quoi occuper un compilateur durant des heures avec beaucoup de mémoire consommée et éventuellement un abandon par K-O technique ^^... Alors qu'en le recompilant, on peut profiter de perfs natives sans éclater la machine.

Maintenant la réalité c'est que le programme obtenu grâce à cette recompilation, ne se débrouille pas tout seul. Le JIT n'a pas vraiment disparu, mais se construit à la demande, dès que l'exécution tombe sur une adresse que l'analyse statique n'avait pas repérée (un appel indirect, typiquement). Sans ce filet de sécurité, le jeu se figerait sur un écran noir. Je vois bien comment ça marche parce que c'est ce que j'ai exploré avec mon outil de recompilation Kompote.

Et ensuite, le jeu recompilé continue de passer par la couche d'émulation de suyu pour ses services système et son GPU. Bref, on est encore loin du jeu Switch qui tournerait tout seul sur votre PC, mais je n'ai aucun doute sur le fait que ça arrivera bientôt.

Notez que les binaires téléchargeables datent tous du 4 septembre, alors que les derniers correctifs ont été committés les 12 et 13. Il faudra donc compiler le code pour profiter de cette dernière version.

Quant à savoir pourquoi le projet s'arrête maintenant, l'équipe n'en dit pas un mot mais je sais juste qu'un avis DMCA de Nintendo avait déjà emporté son dépôt principal en juillet 2024, et qu'un nouvel avis du 17 août dernier avait fait tomber d'un coup 307 dépôts dont l'adresse contenait le mot suyu.

Mais rassurez-vous, ça ne veut pas dire que l'émulation Switch s'arrête pour autant puisqu'un fork a repris le code dans la foulée et enchaîne déjà les versions.

Et Eden , le projet dont suyu descend directement, continue tranquillement sa route sur son propre serveur, loin de GitHub, avec une version publiée en juin et un dépôt encore actif à la mi-septembre. C'est donc là qu'il faut regarder si vous cherchez un émulateur Switch encore suivi.

Source : le dépôt archivé de suyu et l'article de Wccftech

Si vous avez une petite console rétro portable qui traîne, du genre une Miyoo Mini, une TrimUI Brick, une Anbernic RG35XX , vous avez sans doute remarqué que l'interface livrée avec fait le job mais sans plus. Ça tombe bien, spruceOS est là pour ça ! Et malgré son nom, ce n'est pas vraiment un système d'exploitation. En réalité, il s'agit d'un frontend codé en Python qui vient se poser sur une base système déjà existante. Le code est public, sous une licence Creative Commons donc pour les plus capitalistes d'entre vous, ça veut dire pas d'usage commercial sans permission écrite de l'équipe.

Sur les Miyoo et les TrimUI, la base en question est le système d'origine de la console, celui du fabricant. Sur les Anbernic à puce H700 et sur la Powkiddy RGB30, il faut d'abord installer une base tierce sur la première carte mémoire, genre BaseOS pour les Anbernic, dArkMoss pour la Powkiddy. La carte spruce, elle, ira dans le second emplacement, le TF2, et elle restera librement échangeable d'un appareil supporté à l'autre. Rien de dramatique donc, mais ça fait une étape de plus et une carte en plus.

Ce que vous y gagnez si vous installez spruceOS, c'est surtout du confort au quotidien. Vous maintenez le bouton HOME pendant trois secondes et le Game Switcher vous laisse sauter d'un état de sauvegarde à l'autre sans quitter votre partie. Quand vous éteignez la console en plein jeu, elle sauvegarde même toute seule son état et vous remet exactement là où vous en êtiez au rallumage. Et si votre console a le Wi-Fi, vous ne repassez plus par le PC pour l'habiller puisque l'outil Theme Garden pioche dans plus de quatre-vingts thèmes communautaires dispo en ligne, le Game Nursery télécharge des portages gratuits / homebrew, et un scraper récupère même les jaquettes des jeux depuis la base libretro.

Le menu principal de spruceOS, avec les quatre icônes du thème SPRUCE par défaut

Ce qu'il vous faut avant de commencer

Il vous faut une carte microSD neuve, d'une vraie marque, achetée chez un revendeur sérieux ainsi qu'un bon lecteur de cartes. Et bien sûr un ordinateur sous Windows, macOS ou Linux avec une connexion Internet.

Et surtout, n'utilisez pas la carte livrée avec la console. C'est pas moi qui le dit mais le wiki du projet qui est catégorique là-dessus, en majuscules dans le texte : "DO NOT USE THAT STOCK SD CARD!", parce qu'elle est mauvaise, que les jeux dessus sont mauvais et que les BIOS le sont aussi. Donc gardez-la dans un tiroir, elle vous servira pour revenir en arrière en cas de foirage.

L'installation en un clic

L'équipe a sorti un installeur tout-en-un, qu'elle présente comme entièrement open source, disponible pour Windows, Linux et macOS. Il formate la carte, télécharge la version que vous choisissez et l'installe, en une seule opération. Une seule précaution, et le projet la signale lui-même : vérifiez bien que le lecteur que vous désignez est votre carte, parce que l'installeur écrit sur celui que vous lui montrez. C'est le chemin recommandé, et c'est aussi lui qui règle le cas des Anbernic et de la Powkiddy : BaseOS et dArkMoss ont chacun leur onglet dans l'application et se téléchargent puis s'installent automatiquement, sans que vous ayez à aller chercher une image ailleurs.

Un détail qui coince sur Mac, et qui n'est écrit nulle part ailleurs que dans le dépôt : macOS interdit aux applications d'écrire sur un disque amovible sans permission explicite, et l'installeur passe par le Terminal. Il faut donc aller dans Réglages Système, Confidentialité et sécurité, Accès complet au disque, ajouter Terminal, puis quitter et rouvrir le Terminal. Ce dernier point compte, la permission ne s'applique pas à une session déjà ouverte.

Sur Mac, Terminal doit figurer dans Accès complet au disque pour que l'installeur puisse écrire sur la carte ( Source )

L'installation à la main

Si vous préférez faire ça vous-même, il vous faut un utilitaire de formatage et 7zip. Vous formatez la carte en FAT32, avec Rufus sous Windows ou l'Utilitaire de disque sous macOS en choisissant MS-DOS (FAT32). Vous récupérez l'archive spruce.vX.X.X.7z sur la page des versions du dépôt, vous l'extrayez sur votre ordinateur, puis vous copiez le contenu extrait sur la carte. Vous éjectez proprement, vous insérez la carte dans la console et vous allumez.

Et là, attention au piège, puisque le paquet contient un dossier caché nommé .tmp_update, et sans lui spruce ne fonctionnera tout simplement pas. Donc affichez les fichiers cachés avant de les copier : sur Mac c'est Commande + Majuscule + point, et sur Ubuntu le dossier est masqué par défaut lui aussi. Sur Mac, pensez aussi à nettoyer les fichiers .dot parasites avant d'éjecter la carte. Un utilitaire comme CleanEject fait ça très bien.

Vos jeux et vos BIOS

Les ROMs se rangent ensuite dans un dossier Roms, avec un sous-dossier par machine. La plupart des noms sont évidents, mais certains noms piègent tout le monde comme SFC ou FC. Hé oui, les jeux Super Nintendo vont dans SFC, pour Super Famicom, et pas SNES ; les jeux NES vont dans FC, pour Famicom, et pas NES. Les vidéos et la musique, elles, vont toujours dans MEDIA.

Les BIOS se posent dans un dossier BIOS à la racine de la carte, mais il faut les placer dans le sous-dossier qui va bien par machine et pas tout balancer en vrac. Le BIOS de la Dreamcast veut son sous-dossier, certains sont obligatoires pour que la machine tourne, d'autres pas. Donc je vous invite à vous renseigner en fonction de la machine que vous voulez émuler. Et comme d'hab, le BIOS de la NeoGeo ne va pas dans BIOS mais avec les jeux.

BIOS/dc/dc_boot.bin Dreamcast, obligatoire
BIOS/gba_bios.bin Game Boy Advance, facultatif
Roms/NEOGEO/neogeo.zip NeoGeo, obligatoire, et pas dans BIOS

Et évidemment, le projet ne fournit ni ROMs commerciales ni BIOS et ne vous dira pas où les trouver, donc c'est à vous de voir avec vos propres cartouches et vos propres disques.

Si l'écran reste noir

Maintenant, si c'est tout noir au lancement, vérifiez que le dossier .tmp_update est bien présent sur la carte. Remettez-la dans l'ordinateur, réaffichez les fichiers cachés, et regardez : si vous avez copié sans avoir activé l'affichage, il n'y est pas. L'autre suspect, c'est la carte elle-même. C'est peut-être parce que vous avez acheté une no-name de merde.

Le moment où vous ne pourrez plus revenir en arrière

Tant que vous ne touchez qu'à la carte, vous ne risquez rien de définitif. Sur la famille Anbernic RG35XX, les guides de référence le disent tous : ces firmwares vivent entièrement sur la microSD, et donc on peut passer de l'un à l'autre sans modification permanente de l'appareil. Ailleurs le principe est le même, et pour retrouver votre console en version d'usine il suffit donc de remettre la carte d'origine.

Sauf qu'il y a UNE exception !! spruce embarque un Firmware Updater qui apparaît tout seul dans vos applications si votre console tourne sur un firmware ancien. Celui-là n'écrit pas sur la carte mais dans la mémoire interne de la machine, et le wiki prévient sans détour : "Failure to follow the firmware updating instructions can lead to a bricked device.". En gros si vous le lancez pour faire la mise à jour du firmware, ça peut bricker votre console, donc pensez bien à la brancher sur le courant avant la mise à jour. Le projet documente d'ailleurs deux procédures de débriquage, dont une qui demande carrément d'ouvrir la Miyoo Flip et de débrancher sa batterie, ce qui vous dit assez bien à quel point on a quitté le terrain du réversible...

Et si spruceOS ne vous convient pas, vous ne serez pas coincé pour autant car sur ce même matériel, le guide de référence de Retro Game Corps recommande aussi Knulli pour son interface EmulationStation, ou encore muOS pour la performance d'émulation la plus avancée, à condition que le bricolage de configs customs ne vous rebute pas. Après voilà, chaque "OS" a sa carte et vous changez d'avis quand vous voulez.

Source : spruceOS sur GitHub , le wiki du projet et le site officiel

Tomb Raider tourne désormais sur une carte de développement équipée d'un ESP32-P4, un microcontrôleur destiné à piloter des appareils électroniques. Le développeur Alejandro Villegas Alonso, connu sous le pseudo alexkid77, y a adapté OpenLara, le moteur libre qui permet de faire fonctionner le premier jeu avec ses données d'origine.

Pas d'émulateur PlayStation ici. Le programme ne cherche pas à reproduire le fonctionnement complet de la console : il exécute une version du moteur adaptée à cette puce, avec le calcul des images assuré par le processeur. Le travail porte donc sur le jeu lui-même et sur son utilisation des ressources disponibles.

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

La carte retenue s'appelle ESP32-P4-Function-EV-Board. La configuration documentée dispose de deux cœurs à 400 MHz, de 16 Mo de mémoire flash pour stocker le programme et de 32 Mo de mémoire de travail externe. Il faudra ce matériel ou un sérieux travail d'adaptation, pas simplement ressortir n'importe quel ESP32 oublié dans un tiroir.

L'image est calculée en 320 x 240 pixels, puis agrandie pour remplir un écran de 1 024 x 600 pixels. Cette seconde opération utilise le PPA, l'accélérateur de traitement des pixels intégré à la puce, ce qui évite de demander au moteur de dessiner toute la scène dans la définition de l'écran.

Le dépôt annonce 30 images par seconde. Le résultat est assez réjouissant pour une carte qui n'a pas été conçue comme une console de salon.

L'adaptation prend aussi en charge le son, les sauvegardes sur carte microSD et un compteur d'images par seconde que l'on peut afficher avec F12. Un clavier USB est nécessaire pour jouer : les flèches servent aux déplacements, et la barre d'espace permet de sauter.

Pour préparer la carte, le développeur indique d'utiliser ESP-IDF, l'environnement de développement d'Espressif, en version 5.4 ou plus récente. Il faut compiler le projet, puis transférer le programme sur le microcontrôleur. Du coup, ce téléchargement vise surtout ceux qui aiment déjà bricoler du matériel.

Les fichiers du jeu doivent être ajoutés séparément dans un dossier data sur la microSD. OpenLara fournit le moteur, pas les niveaux et les images du Tomb Raider commercial, et le portage ne fonctionne pas sans ces données. La documentation précise aussi que les sauvegardes et le cache sont écrits sur cette carte.

Perso j'aime bien ces projets qui donnent un nouveau terrain de jeu aux vieux moteurs.

Source : Hackaday

Un développeur espagnol, Emilio Cano Pérez, vient de publier le SDK de son CanoFlash, un petit boîtier monté sur un XIAO ESP32-S3 qui se branche sur le port Link d'une Game Boy Advance. Cela ne nécessite aucune modification de la console, ni de fer à souder (cool !), et une fois branché, ça permet à la console de récupérer la connexion Wi-Fi qu'elle n'a jamais eue !

Alors comment ça fonctionne ? Hé bien le truc démarre en mode Multiboot et pousse sa propre application dans la RAM de la console. Ensuite c'est lui qui se coltine la gestion de tout le réseau, pendant que la GBA se contente d'échanger avec lui des paquets de taille fixe. En clair, un jeu n'a pas à connaître l'existence du Wi-Fi. Il parle juste au boîtier à travers le SDK dispo sur GitHub, qui lui apporte le matchmaking public, les salons privés et des parties jusqu'à huit joueurs.

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Sauf qu'avant de sortir votre Game Boy du tiroir, il faut lire la FAQ du créateur parce qu'il y écrit que le jeu en ligne fonctionnera uniquement dans les jeux qui intègrent son SDK, et qu'il ne transforme pas automatiquement le multijoueur Link des jeux existants en multijoueur Internet. Roooh, c'est dommage quand même. Ça veut donc dire que votre cartouche collante de Pokémon Rubis ne fonctionnera pas via le Wi-Fi... Pour jouer, il vous faudra donc des homebrews compilés avec le kit, plus un boîtier et une console par joueur.

Maintenant, si c'est vraiment vos vieilles cartouches que vous voulez faire jouer à distance, l'appareil qui fait ça, c'est le GB-Link USB dont je vous ai parlé en juin . Lui se fait passer pour un câble Link, se relie en USB-C à un ordinateur ou à un smartphone Android, et un client web différent parle le protocole de chaque jeu : les échanges Pokémon des trois premières générations, les parties d'Advance Wars. Dans le même genre, ChisLink est un projet à monter soi-même dont le relais transporte les paquets des jeux compatibles avec l'adaptateur sans fil de Nintendo.

Cette limite du CanoFlash n'est d'ailleurs pas une bizarrerie de conception, parce que l'adaptateur sans fil sorti par Nintendo en 2004, c'était exactement pareil. Il était fonctionnel avec seulement à 46 jeux compatibles, tous sortis entre 2004 et 2006. Ça ne remplaçait pas non plus le câble Link.

Du coup, le CanoFlash, son vrai métier, c'est surtout de vous permettre de parcourir vos homebrews et vos sauvegardes personnelles via Wi-Fi, de flasher le jeu de votre choix sur votre cartouche réinscriptible et de synchroniser les sauvegardes, le tout sans PC.

Par contre, cette cartouche réinscriptible compatible dont je vous parle, à base de S29GL256, elle est indispensable et elle n'est ni incluse ni vendue dans la campagne Kickstarter CanoFlash. Même chose pour la batterie, même si le boîtier accepte de tourner sur USB-C. Donc comptez le prix de la cartouche en plus avant de vous emballer, et sachez aussi que la campagne Kickstarter n'est toujours pas lancée à l'heure où j'écris ces lignes.

Le SDK, lui, est déjà là , et il se compile sans avoir le moindre boîtier sous la main. Bref, de quoi préparer votre jeu tranquillement en attendant que le matériel existe...

Source : XDA Developers

Le développeur Mayuki Sawatari vient de publier ReProgman , un clone du Program Manager de Windows 3.1.

Ça ne vous dit rien ? C'est parce que vous êtes des bébés !

En fait, progman.exe, c'est ce truc qui servait d'interface principale à Windows avant que le menu Démarrer ne débarque avec Windows 95. Et aujourd'hui, grâce au taf de Sawatari, ça tourne aussi bien sur Windows 11 que sur macOS.

Pour ceux qui ont commencé l'informatique après 1995, faut savoir qu'avant ça, on n'avait pas de bureau, pas de barre des tâches, mais juste une grande fenêtre grise remplie de sous-fenêtres, et dans chaque sous-fenêtre y'avait des icônes de programmes alignées sur une grille. Vous double-cliquiez sur l'une d'elles, le programme se lançait, et voilà, vous aviez fait le tour de Windows !

Le groupe Main ouvert sur Windows 11, et la rangée de groupes réduits en bas de la fenêtre

Regardez bien les icônes sur cette capture : Docker, Edge et Claude rangés dans une ambiance de 1992...

Car ReProgman ne se contente pas de reproduire la déco. Au premier lancement, il scanne votre menu Démarrer (ou vos dossiers Applications si vous êtes sur Mac), transforme chaque dossier en groupe et range le tout dans son propre fichier Groups.ini. Après ça, il n'y retourne plus tout seul, et ce que vous déplacez, renommez ou supprimez dedans ne redescend jamais vers vos vrais raccourcis. Un menu permet quand même de relancer l'import à la main, et il n'ajoute alors que ce qui manque.

Du coup, vous récupérez les gestes de l'époque pour de vrai. Vous attrapez une icône, vous la lâchez dans une autre fenêtre et elle déménage, avec Ctrl enfoncé elle se copie, le menu Window vous range tout ça en cascade ou en mosaïque, et les fenêtres réduites redeviennent des icônes alignées en bas de la fenêtre principale. Même la boîte de dialogue de sortie a été refaite, à ceci près qu'elle annonce la fin de votre session ReProgman et non celle de Windows.

Maintenant, d'où ça sort comme délire ?

Hé bien, l'auteur raconte, dans un message relayé par Tom's Hardware, qu'il a simplement demandé à Claude de lui fabriquer ce clone, et que la première version obtenue en une heure était déjà plutôt correcte, même s'il a ensuite fallu rattraper les imperfections.

Ce qui est intéressant, c'est que dans son dépôt git, on trouve un document de spécification de plusieurs centaines de lignes qui décrit l'interface au pixel près, relevée sur des captures 640x480 du Windows original. Le cadre d'une fenêtre y fait 1 pixel noir, 2 pixels gris et encore 1 pixel noir, et la petite barre du menu système mesure 13 pixels sur la fenêtre principale contre 7 sur une fenêtre enfant. C'est d'ailleurs comme ça qu'on les distinguait à l'époque.... Fallait avoir l'oeil !

Si vous voulez l'essayer, ça se présente sous la forme d'un binaire autonome. Par contre sur Mac, la version distribuée n'est pas notarisée, il faudra donc lui passer un xattr -cr ReProgman.app ou utiliser Sentinel avant qu'elle accepte de démarrer. Ah et le code est sous licence MIT.

Le périmètre annoncé par le projet est d'ailleurs plus étroit qu'il en a l'air, puisque c'est Windows 11 en x64 et en Arm, et macOS uniquement sur Apple Silicon. Donc si vous êtes resté sur Windows 10 parce que vous aimez le risque ou sur un Mac Intel parce que vous aimez prendre votre temps, il n'y a rien pour vous amuser... Il faudra alors retourner du côté de ce musée de vieux systèmes d'exploitation que je vous avais montré, qui lui passe par l'émulation.

Après, je pense pas que vous y ferez votre vie mais ça vous donnera environ 30 secondes de nostalgie avant de refermer la fenêtre. C'est déjà ça de pris...

Source : Tom's Hardware

Une vidéo postée sur X montre Super Mario 64 qui tourne sur une machine ARM, sous un système qui n'est ni Windows ni Linux. Oui, c'est bien ReactOS, le clone libre de Windows, et le jeu est un exécutable x64 tout ce qu'il y a de plus banal !

Et n'allez pas croire que c'est un émulateur qu'on aurait posé sur un OS libre. Que nenni ! Pour exécuter du x64 sur de l'ARM, il faut deux trucs qui n'ont rien à voir l'un avec l'autre : un moteur qui traduit les instructions du processeur, et un système capable de faire cohabiter du code natif et du code traduit dans un même programme.

La première moitié, c'est FEX, l'émulateur financé par Valve dont je vous parlais en décembre. Sauf que côté Windows, FEX se limite au processeur : sa propre documentation précise que la traduction des appels système revient soit à Wine, soit à l'ABI du système. Tout le reste est alors à la charge de l'hôte.

Cette seconde moitié porte un nom, ARM64EC, et c'est une invention de Microsoft pour Windows 11 sur ARM (oui, la boîte que ReactOS passe justement son temps à recopier). Le principe consiste à compiler les bibliothèques du système en ARM64 avec une interface appelable depuis du code x64 recompilé. Du coup, un même programme mélange des morceaux natifs et des morceaux émulés, et seul ce qui doit vraiment l'être passe par l'émulateur. L'intérêt de faire comme ça, c'est surtout la vitesse !

Jusqu'ici, deux entités avaient bâti cet "étage" : Microsoft dans Windows, et Wine depuis sa version 10 . ReactOS est donc la troisième. Son développeur Ahmed Arif a ainsi écrit son propre runtime hybride dans le ntdll du système, avec le chargeur d'images, les ponts qui rendent les fonctions natives appelables en x64, et le déroulement de pile.

Ensuite, pour vérifier que tout se tient, il fait tourner le même binaire des deux côtés, sur son ReactOS et sur un vrai Windows 11 ARM64, puis il compare.

Screenshot

Alors, est-ce que vous pouvez l'installer ?

Et bien malheureusement, non !

Tout ce boulot n'existe que dans une branche d'un fork personnel, et le dépôt officiel de ReactOS n'en contient pas la moindre ligne. Et c'est mieux pour l'instant car, comme Ahmed le dit lui-même, son fork est encore plus expérimental que ReactOS lui-même ! C'est donc à réserver aux machines virtuelles, aux cartes de développement ou aux bécanes sans données sensibles. Bref, venant d'un projet qui se présente déjà lui-même comme un système de qualité alpha, ça vous situe l'ambiance...

Bref, rien à télécharger mais pour un projet qui se battait encore il y a trois mois pour lancer Half-Life , voir un jeu x64 démarrer sur de l'ARM, ça envoie quand même du pâté.

Source : Phoronix

Vous vous souvenez de GTA Vice City ?

Non ? C'est normal, c'est un petit jeu qui est passé relativement inaperçu ^^. Dans ce jeu, on est plongé dans le Miami des années 80, avec ses chemises à fleurs, Tommy Vercetti et la radio à fond dans une décapotable volée.

Eh bien bonne nouvelle pour les fans, le jeu tourne aujourd'hui en entier dans un onglet de votre navigateur, sans rien avoir à installer, et ça s'appelle reVCDOS.

Derrière, c'est reVC, on retrouve la décompilation du moteur du jeu dont je vous ai déjà parlé, recompilée en WebAssembly par l'équipe de DOS.Zone. Autrement dit, ce n'est pas de l'émulation mais le vrai moteur d'origine qui tourne direct dans un browser.

Et ça se joue comme vous voulez, au clavier et à la souris, à la manette, ou carrément du bout de votre doigt tout gras sur un téléphone en portrait comme en paysage.

Les codes de triche marchent aussi, tapés au clavier comme à l'époque, et vous pouvez charger vos propres mods dans le navigateur avec des fichiers dff et txt qui sont supportés tels quels, sans conversion.

Si vous êtes chaud, pour jouer, ça se passe sur la page du projet . Le jeu a besoin des données de Vice City, et le site vous propose cinq façons de les lui donner : Il y en a 2 qui les téléchargent pour vous, dont un torrent, et 3 qui vous laissent envoyer les vôtres, en dossier, en fichiers ou en zip. Je vous conseille la deuxième méthode, car la première, c'est du piratage, et le piratage, c'est maaaal ! Et ouais, il faut bien financer les petits studios comme Rockstar.

Bref, il vous faut les fichiers du jeu d'origine mais bonne nouvelle : sur Steam, on trouve encore aujourd'hui la Definitive Edition, à 59,99 €. Franchement, pour un jeu sorti y'a 24 ans, c'est vraiment donné, non ? Ah bah oui, je vous l'ai dit, il faut financer les petits studios.

Et si vous préférez héberger le bidule vous-même, sachez que le dépôt Github du projet publie les binaires et une image Docker qui convertit vos fichiers au format attendu ! Comptez une cinquantaine de mégas au démarrage, le reste arrive en cours de partie.

Un truc à savoir avant de vous lancer, parce que ça pique : les sauvegardes locales sont pétées depuis des mois, et l'auteur a fini par lâcher sur son forum que "les sauvegardes ne sont disponibles qu'avec un abonnement". Donc si vous vous lancez dans une partie, il faudra jouer jusqu'au bout. Ou alors, vous vous démerdez pour débuguer votre install.

Et profitez-en tant que c'est là, parce que Take-Two a déjà fait tomber ce portage à coups de DMCA l'an dernier. Bref, un tour à Vice City ce soir, ça ne se refuse pas.

Source : Tom's Hardware

Ce jeu, ou plutôt cette expérience, je vous le dis tout de suite, ça ne va pas changer votre vie. Au contraire, ça risque même d'aggraver vos PTSD en rapport avec les sports d'hiver. Moi, ça va, je ne suis jamais allé à la montagne en vacances l'hiver, parce que je n'étais pas assez richou étant + jeune, donc, c'est au moins un trauma que je n'ai pas !

Dans Line Rider , vous tracez une ligne à la souris, vous appuyez sur play, et un petit bonhomme en luge dévale la pente que vous venez de dessiner à pleine balle. Voilà c'est tout !

Alors, je pense que si vous êtes un ancien, vous connaissez forcément, parce que ce truc n'est pas de première fraîcheur. C'est sorti en 2006 sur DeviantArt . Ça a été créé par Boštjan Čadež, un étudiant de l'Académie des Beaux-Arts de Ljubljana, pour un devoir de son cours d'illustration. À l'époque, il y a eu quand même 10 000 personnes qui l'ont vu dans les 24 heures de la sortie du jeu. Et un mois plus tard, on en était à 4 millions de vues et 325 000 téléchargements du jeu.

Notez quand même que la toute première version n'avait même pas de gomme et c'était volontaire de la part de Boštjan. Sauf qu'aujourd'hui ce n'est plus le Flash de 2006 que vous lancez mais une réécriture complète pour le web moderne, signée David Lu avec Matthew Henry et Tobias Bessler.

Et la réécriture a pris du muscle puisque vous avez maintenant trois types de ligne (la bleue qui porte, la rouge qui accélère, la verte qui ne sert qu'au décor), des calques, une pelure d'oignon pour suivre la trajectoire, jusqu'à six lugeurs en même temps, et un moteur de scripts pour piloter la caméra ou la gravité.

Attention quand même : Ne lancez que des scripts dont vous connaissez la provenance ^^. Par contre, n'oubliez pas que les lignes ont un sens. Si vous les tracez de la gauche vers la droite, elles feront office de sol. Par contre, si vous les tracez dans l'autre sens, votre petit gugusse va s'y cogner par en dessous ou la traversera sans la voir s'il y arrive par le dessus.

Vous pouvez aussi glisser un fichier audio dans l'éditeur pour caler l'animation sur la musique. C'est comme ça que la communauté sort ses morceaux de bravoure, genre les 39 millions de vues de la piste que DoodleChaos a synchronisée sur "In the Hall of the Mountain King".

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Ensuite, concernant l'export vidéo, le bouton sort bien un MP4, mais celui-ci sera muet. La musique que vous avez chargée sert uniquement à caler l'animation pendant que vous dessinez, et la synchro, vous devrez la faire ailleurs, dans OBS ou un vrai logiciel de montage.

Côté mobile par contre, c'est plus tristoune. L' application Android est à 2,99 € et n'a plus bougé depuis juillet 2023, et la fiche App Store vers laquelle le site pointe toujours renvoie un beau 404. Bof donc...

Le web reste donc le seul endroit où Line Rider est vraiment vivant.

Le code, lui, est fermé. David Lu n'a sorti que le moteur physique, dans un dépôt sans aucune licence et qui n'a plus évolué depuis 2017. Alors si vous voulez du libre pour de vrai, allez voir plutôt LROverhaul , un descendant de Line Rider Advanced sous GPL-3.0 qui tourne sur le bureau.

Merci à j0j0b4rj0 pour le lien !

Source : linerider.com

En mai 1996, sur le forum Usenet consacré à Quake , des joueurs prenaient déjà les paris... Le jeu n'était pas sorti, le CD non plus, et la question qui tournait en boucle à l'époque c'était : combien de temps tiendrait la protection anti-copie du jeu ? Certains misaient deux semaines après la sortie, d'autres 5 jours maximum...

De son côté, id Software s'apprêtait à presser son shareware sur un disque mais Quake n'occupait que 22 Mo des 640 disponibles. Du gâchis de place ? Pas vraiment puisque le reste du CD a été rempli avec tout le catalogue maison. Des jeux complets en versions chiffrées, c'est-à-dire plusieurs DOOM, Final Doom, Hexen, Heretic qu'on déverrouillait par téléphone...

Source

Le CD est finalement sorti le 30 août 1996 et le concept était bien pensé, sur le papier en tout cas... Le programme affichait un nombre de onze chiffres, les Américains appelaient le 1-800-ID-GAMES, un opérateur encaissait la thune et donnait en échange un numéro de déverrouillage à retaper. Le premier nombre changeait à chaque lancement et tournait toutes les 5 minutes, précisément pour qu'un code ne puisse pas servir deux fois.

Mais le 8 octobre suivant, coup de tonnerre ! Le groupe GNOMON sortait QCRACK.EXE pour faire tout sauter ! Ça n'aura pris que 39 jours !

source

Ce qu'ils avaient compris, c'est que le numéro donné au téléphone ne contenait aucun secret. Il attestait simplement du paiement et de rien d'autre. Le programme livré sur le CD savait fabriquer ce numéro tout seul à partir de celui qu'il venait lui-même d'afficher, et son seul travail consistait donc à comparer les deux.

Toute la protection tenait, comme souvent, dans le fait que personne n'était censé regarder comment ça fonctionnait.

Source

Toutefois, ce mécanisme de vente n'était pas vraiment une bourde d'id Software. Eux n'étaient que les clients de TestDrive Corp, qui vendait cette solution brevetée .

Et ce brevet expliquait très précieusement comment ça fonctionnait... Le poste de l'utilisateur produit un numéro, l'opérateur distant le valide et renvoie un code d'activation, et c'est le poste de l'utilisateur qui vérifie ce code. Le brevet va même jusqu'à donner son exemple, à savoir un numéro dont les chiffres totalisent 10, et un code de retour dont les chiffres totalisent 15.

La faille était donc déposée à l'office des brevets quatre ans avant que le CD arrive en rayon.

Le reste raconte quand même une fin de production difficile. La base qui associe chaque jeu à son identifiant contenait également une faute de casse sur Final Doom, "Final" au lieu de "final", ce qui envoyait la génération du code chercher le mauvais fichier. Résultat, le client qui appelait et payait pour Final Doom n'arrivait pas à le déverrouiller.

Alors que le pirate, lui, y arrivait à tous les coups !

Et si je vous raconte tout ça c'est surtout parce que Fabien Sanglard s'est amusé à redémonter le CD-Rom cet été , et qu'il y a aussi trouvé de jolies surprises comme une version en clair de cette base posée juste à côté de sa version chiffrée + des fichiers temporaires et des sauvegardes d'éditeur oubliés au pressage.

Je vous invite vraiment à lire son analyse, c'est super intéressant !

Source : PC Gamer

Enfin !! Le compteur du projet de décompilation de GoldenEye 007 affiche dorénavant 208 fichiers traités sur 208, et cela pour les trois versions de la cartouche, japonaise et européenne comprises. Le dernier commit du dev KholdFuzion est d'ailleurs classe, puisqu'il porte le titre "*james bond will return. *".

Oh yeah !

Techniquement, le code C reconstitué ressort du compilateur sous la forme d'une ROM identique à celle de 1997, octet pour octet. C'est précisément ce que veut dire le mot "matching" dans ces projets. Ce n'est donc pas un jeu équivalent qui se comporterait pareil que le jeu d'origine... Non, c'est exactement le même binaire !

Après comme vous vous en doutez, le dépôt, lui, n'embarque pas tous les assets nécessaires à la compilation, pour des questions de droits d'auteur comme d'hab. Le README du projet nous explique ainsi qu'il faut posséder une copie du jeu, et que les scripts iront extraire ce qui manque de votre côté.

Après c'est pas cette recompilation qui fait que GoldenEye devient soudainement "moddable". En effet, il l'est depuis longtemps, via le GoldenEye Setup Editor de SubDrag, Wreck et Zoinkity, capable d'importer vos propres modèles 3D dans le jeu.

Ce qui change par contre, c'est que jusqu'ici on éditait des structures dans un binaire, alors que maintenant on modifie le moteur en C et on recompile. C'est le même chemin qu'avait pris ce bon vieux Duke Nukem Zero Hour l'an dernier .

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Et c'est d'ailleurs ce que fait KholdFuzion à côté, avec GoldenRecomp , qui recompile la ROM en exécutable PC natif. Avec ça, le jeu peut tourner sur un ordinateur. Apparemment, c'est plutôt stable, et le son est bon.

Mais toute l'interface multijoueur reste à faire, le ciel du barrage part en vrille parce que le moteur de rendu ne digère pas les commandes de dessin maison, et certaines armes tirent trop vite maintenant que tout tourne à 60 images par seconde. Ce n'est donc pas encore vraiment jouable.

Aucune release n'a été publiée à ce jour, ni même un tag, ce qui veut dire qu'on est encore loin d'un portage installable comme celui de Zelda 64 . Faudra compiler vous-même, après avoir "build" une ROM depuis la branche du projet conçue pour ça.

Dans le même style, n'oubliez pas l'existence de GoldenEye-Recomp de SunJaycy , qui lui, est déjà jouable avec du multijoueur en ligne, mais qui n'a rien à voir avec tout ça puisqu'il recompile la version Xbox 360 qui n'est jamais sortie, et pas la N64.

Bref, si vous attendiez un exécutable à lancer ce soir, ce n'est pas ce que vous aurez mais ce qui s'annonce ensuite est très prometteur !

Source

Jonas Eschenburg se tape un petit délire cet été, en portant Command & Conquer sur Atari ST, et il vient de s'occuper des cinématiques du jeu, le tout sur une machine équipée d'un Motorola 68000 cadencé à 8 MHz. Le même garçon avait déjà fait tourner Doom dessus.

Le décalage vaut le détour. Command & Conquer sort en 1995 sur PC, en VGA 256 couleurs, soit dix ans après l'Atari ST, qui affiche lui 16 couleurs en 320 par 200 points.

Envoyer les pixels bruts à l'écran est hors de question sur ce genre de matériel. La machine n'a ni le débit de lecture ni la puissance de calcul pour ça.

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Eschenburg a donc écrit son propre codec, baptisé STV, adapté du format VQA que Westwood utilisait à l'époque pour ses vidéos. Le principe repose sur un codebook, autrement dit un dictionnaire de petits carrés de pixels : au lieu de transmettre chaque image entière, le fichier envoie surtout des numéros qui pointent vers des motifs déjà connus du lecteur.

L'astuce est en réalité ailleurs. Les blocs sont découpés pour tomber pile sur l'organisation mémoire de l'Atari, qui range ses couleurs en plans séparés plutôt qu'en pixels contigus, ce qui permet au processeur de recopier les motifs sans passer son temps à réorganiser les bits.

La palette et le dictionnaire se mettent à jour en continu pendant la lecture, et pas une fois pour toutes au début du fichier. Ça évite le gros pâté de blocs baveux qu'on attendrait d'une compression aussi agressive.

Le tout fonctionne sur un 8 MHz d'origine. Sans accélérateur. A priori, aucun jeu Atari ST n'avait affiché de vidéo plein écran avant celui-là.

Le jeu, lui, reste beaucoup plus poussif pour le moment : quelques images par seconde en 16 couleurs, correct seulement à partir d'un Falcon, et il réclame 4 Mo de mémoire. Autour du codec, Eschenburg a publié une dizaine d'utilitaires, dont un encodeur pour fabriquer les fichiers STV et un lecteur natif pour les regarder sur la machine.

Tout est sous licence GPL sur GitHub, le portage se récupère sur itch.io, et il faut fournir ses propres fichiers du jeu d'origine puisque le projet n'a rien à voir avec EA.

Détail amusant, le son ne sort que sur STe et Falcon. Sur un ST de base, les cinématiques défilent en silence complet. La question étant maintenant de savoir si tout ça ne m'a pas donné envie de rejouer à Command and Conquer, pour ressortir mon premier pseudo de game : Moissonneuse killer (vraiment).

Source : Hackaday

Si vous êtes fan de The Elder Scrolls III: Morrowind, j'ai une bonne nouvelle pour vous : vous allez pouvoir y jouer directement dans un onglet de navigateur ! En effet, c'est ce que nous propose openmw-web , signé Virtastic et sorti il y a quelques jours !

openmw-web fait donc tourner Morrowind dans un browser en recompilant OpenMW vers WebAssembly avec Emscripten. OpenMW, c'est le moteur libre qui réimplémente de zéro celui du jeu, et l'avoir en WebAssembly, ça permet de le faire tourner localement sur votre machine dans le navigateur.

Si vous voulez tester, il y a deux façons de vous lancer. Soit via le monde de démo livré avec OpenMW qui est jouable direct avec un petit village, ses PNJ, ses gardes et des créatures qui rôdent autour.

Ou alors vous pointez le navigateur vers le dossier Data Files de votre propre installation. Les fichiers sont alors lus en streaming depuis le disque via la File System Access API, rien n'est uploadé nulle part, et Tribunal, Bloodmoon et vos mods en .esp, .esm ou .bsa sont détectés tout seuls.

Dans ce mode, les sauvegardes atterrissent ensuite sous la forme de vrais fichiers dans un sous-dossier openmw-web-saves, donc vider le cache du navigateur ne les effacera pas. Alors que sur le monde de démo, elles resteront dans le stockage du navigateur, et là si vous videz votre cache en mode bourrin, vous perdrez votre avancement.

J'ai lancé la démo, et je dois dire que ça tourne plutôt bien.

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Virtastic est une boîte dont c'est le métier de recompiler des logiciels desktop en applis web. Ils vendent la prestation de conversion, la maintenance et l'hébergement, et licencient leur bibliothèque de dépendances déjà cross-compilées vers WebAssembly, genre Qt, CPython, OpenCASCADE ou FFmpeg.

Donc Morrowind c'est leur vitrine, avec FreeCAD et Jagged Alliance 2 en preview et Blender annoncé. Ça explique la finition du truc, car le gros du travail était surtout dans la chaîne de dépendances, et pas forcément dans le jeu.

Notez que de ce que j'ai lu dans la doc, sous Windows, visiblement le navigateur refuse d'ouvrir un dossier situé dans Program Files, là où Steam installe par défaut. Il faut donc copier Data Files sur le Bureau ou dans Documents avant de le sélectionner.

Le développeur a évoqué également un mode multijoueur parmi les fonctions à venir, ce que le jeu n'a jamais eu d'origine. Et sur le dépôt, il tient sa roadmap sous forme de tickets qu'il s'ouvre à lui-même.

Je vous parlais d'OpenMW en 2012 , quand c'était encore un moteur prometteur en cours d'écriture et nous voilà 14 ans plus tard, et ce même moteur tourne dans un Chrome OKLM. C'est beau non ? Dans le genre vieux logiciel qui déménage dans le navigateur, y'a aussi ce émulateur x86 en WebAssembly qui reste mon autre chouchou.

Amusez-vous bien !

Source

727 mots de passe testés par seconde, c'est le score incroyable d'une Game Boy Advance reprogrammée en casseur de mots de passe par solst-ice, un développeur qui avait visiblement une console de 2001 qui traînait et pas mal de temps à tuer ^^. Son projet s'appelle GBA-Hashcat, et c'est un "port" de hashcat (le célèbre outil de crackage) sur le petit hardware portable de Nintendo.

Enfin, un port entre grosses guillemets, parce que le vrai hashcat gère plus de 300 algorithmes de hash optimisés et une palanquée de méthodes d'attaque alors que là, vous avez le droit à un seul truc, du SHA-256, et rien d'autre.

Le programme embarque la wordlist ignis-1M, une liste de 8 Mo qui contient environ 1 million de mots de passe parmi les plus courants. Pour chaque ligne, la GBA calcule le hash SHA-256, le compare à un hash cible codé en dur dans le programme, et regarde si ça correspond.

C'est une attaque par dictionnaire, quoi, sauf que, je vous rappelle, ça tourne sur une puce ARM7TDMI cadencée à 16,78 MHz avec 288 Ko de RAM.

Du coup, forcément, ça rame de fou... au rythme de 727 hachages par seconde mais c'est normal car cette console n'a jamais été pensée pour ce genre de calcul. Pour vous donner une idée, un PC moderne avec un GPU décent va environ 30 millions de fois plus vite, soit des milliards de tentatives par seconde.

Alors que la GBA, elle, met une bonne vingtaine de minutes à avaler toute sa liste de 1 million de mots.

Après côté bidouille c'est assez fort car, certes, la wordlist de 8 Mo tient dans la cartouche, mais faire tourner une routine SHA-256 propre sur une puce aussi poussive, avec ses malheureux 288 Ko de RAM pour bosser, il faut le vouloir ! Solst-ice s'est donc appuyé sur le moteur Butano, un framework C++ open source taillé pour développer des jeux GBA, qu'il a détourné pour faire mouliner des hashs à la place de sprites.

Et voilà, ce projet loufoque rejoint la longue tradition des gens qui font faire n'importe quoi à leur Game Boy Advance, comme ce clavier GBA à monter soi-même que je vous montrais récemment.

Bref, comme un ministre ou un notaire, ça ne sert strictement à rien, et c'est pour ça qu'on kiffe ! Le code est sur le GitHub de solst-ice si vous voulez jouer.

Source

Y'a un moddeur de génie, Dryxio, qui vient de réussir un truc que Rockstar n'a jamais osé faire : Faire tourner GTA III et Vice City en entier, à l'intérieur de GTA San Andreas. Ouèp, les deux jeux complets, avec leur mode histoire, leurs sauvegardes et leurs réglages !

Dans San Andreas, CJ peut allumer la télé de sa baraque sur Grove Street, ou une borne d'arcade, et hop, une partie de GTA III ou de Vice City se lance. Chaque jeu tourne comme un moteur séparé injecté dans le processus de San Andreas. Du coup vous vous retrouvez avec 3 villes, Liberty City, Vice City et San Andreas, empilées dans une seule fenêtre.

Vous vous souvenez d'AIM ? Mais siiii, le petit bonhomme jaune qui courait, la porte qui claque quand un pote se connecte, les away messages passifs-agressifs à base de paroles de chanson... Et bien la bidouilleuse Veronica a remonté son propre serveur AIM, et ça a l'air de plutôt bien fonctionner

Pour reposer un peu le cadre, AOL a débranché AIM fin 2017. Depuis, les millions de screen names de l'époque pointent dans le vide (Moi c'était FoxMDE ^^), et tous les vieux clients qui traînent actuellement sur vos disques durs ou CD-Rom se connectent à un serveur qui n'existe plus.

Fin de l'histoire, normalement (?).

Bah pas vraiment car AIM tournait sur un protocole qui s'appelle OSCAR, et qui est le même que celui d'ICQ. Du coup, un développeur du nom de mk6i a réimplémenté ce truc en open source, baptisé Open OSCAR Server . En gros, vous faites tourner le serveur sur votre propre machine, vous dites à votre vieux client AIM d'aller taper là plutôt que chez AOL, et hop, vous revoilà en 2003. Veronica utilise ainsi AIM 5.1 sur ses bécanes, et elle héberge le sien sur un petit VPS Debian qui coûte trois francs six sous.

Alors pourquoi avoir fait ça ? Eh bien comme elle le dit elle-même, Discord commençait à la gonfler, et elle avait la nostalgie du lycée. Je vous traduis le passage, il est chouette car je m'y suis bien retrouvé : "Au lycée, la plupart de mes journées commençaient et finissaient par AIM. C'était avant que tout le monde ait des SMS (ou des téléphones portables). Tout, des projets de classe aux relations entières, se passait dans une fenêtre AIM."

Voilà. On a tous connu ça, certains avec MSN ou ICQ...

Alors ça, c'est un sacré morceau qui va ravir tous les fans de rétro gaming ! Patchzy, le dev de Wheel Wizard (le launcher de Retro Rewind), vient d'annoncer Mario Kart Wii compiled, ce qu'il présente comme le premier jeu Wii recompilé en natif pour PC. Pas émulé, hein recompilé. Et vous allez voir pourquoi c'est mieux !

alors pour le moment c'est pas encore dispo, mais c'est une annonce qui est faite en amont de la sortie en bêta qui aura lieu au mois d'août. Cette version de Mario Kart est la première recompilation statique d'un jeu Wii. L'avantage de la recompilation, c'est qu'on peut lui ajouter de nouvelles fonctionnalités et il y aura notamment du jeu en ligne, de la 4K (avec les textures de 2008 dedans par contre...), un framerate débloqué, ainsi qu'un support optionnel de Retro Rewind, ce qui lui apportera plus de 200 circuits.

On a donc une date et on a donc cette vidéo qui va vous mettre l'eau à la bouche :

La recompilation statique, pour faire simple, ça prend le code machine du jeu et ça le retraduit en programme natif pour votre PC. Pas de couche d'émulation qui fait tourner une Wii fantôme en arrière-plan, juste un exécutable que vous lancez comme n'importe quel jeu Steam.

La scène sait faire ça sur N64 depuis un moment, et c'est comme ça que Banjo-Kazooie a atterri sur PC en 4K , et quelques projets s'y sont collés sur Xbox 360. Pour ma part, moi je suis en train de coder une espèce de recompilateur universel qui supportera plein de consoles différentes, mais c'est pas encore prêt et je sais pas encore si je mettrai ça sous licence libre ou si ce sera juste un binaire pour mes Patreons. On verra bien, c'est pas fini, et je prends mon temps mais c'est un petit peu mon passe-temps du moment.

Au moment où j'écris cet article, je suis en train de bosser sur la recompilation de l'ensemble des jeux N64 :

Après sur Wii, le terrain n'était pas complètement vierge non plus, puisque DolRecomp, un recompilateur statique GameCube et Wii, traîne sur GitHub depuis le mois de juin. Alors pourquoi est-ce qu'on s'excite tous si on peut déjà faire tourner Mario Kart Wii nickel sous Dolphin depuis des années ?

Eh bien parce que comme je vous le disais, en théorie, un binaire natif, déjà ça vous épargne tous les problèmes liés à l'émulation, je pense à la surcharge que ça peut engendrer sur les petites configs ou les petits lags, ce genre de choses.

Puis en plus ça peut permettre de supporter par exemple des mods. Je pense à Retro Rewind évidemment, mais pourquoi pas aussi implémenter des nouvelles fonctionnalités dans le jeu. Et puis ça suivra les évolutions de votre machine sans que vous ayez à vous traîner un émulateur... C'est ça qui rend par exemple la recompilation PC d'Animal Crossing intéressante.

En tout cas, ce qui est sûr, c'est qu'avec Patchzy, ça va être du lourd ! En plus, comme Nintendo vient d'annoncer la fin des serveurs de Mario Kart Tour pour le 29 septembre, cette bêta d'août va pouvoir prendre le relais donc ça c'est super cool !!

Après côté légal, le projet ne distribue aucun asset Nintendo, ce sera donc à vous de fournir votre propre ROM. On verra bien si ça empêche Nintendo de dégainer ses avocats...

Source

Un bidouilleur du nom de Throaty Mumbo a décidé de s'attaquer à la Game Boy Color (sortie en 1998, ça ne nous rajeunit pas) pour y faire tourner YouTube ! Et du vrai YouTube hein, en streaming, sur 160x144 pixels. Ça s'appelle GBCYoutube et je vous explique tout en détail...

Ce qu'il a fait en fait, c'est se bricoler une cartouche maison avec dedans, un microcontrôleur RP2350B (le cerveau du Raspberry Pi Pico 2) qui fait tourner le lecteur, et une puce ESP32-C6 qui sert juste de pont WiFi. Vous tapez le titre d'une vidéo sur un clavier affiché à l'écran, la console balance l'info à votre PC, et là yt-dlp récupère la vidéo pendant que ffmpeg l'encode à la volée. Les images repartent ensuite par WiFi vers la cartouche qui les pousse à l'écran en flux continu, sans avoir besoin de stocker quoi que ce soit. Je vous laisse mater la vidéo, c'est impressionnant :

Les développeurs de Dolphin viennent de mettre un point final à un truc qu'ils se traînaient depuis 16 ans : leur émulateur GameCube et Wii sait maintenant émuler le Game Boy Player.

Pour tester ça, faut charger une ROM Game Boy via le réglage "Game Boy Player ROM" planqué dans les paramètres GameCube de Dolphin, puis vous lancez le Start-Up disc officiel du Game Boy Player ou le homebrew Game Boy Interface, et c'est parti ! L'émulateur attache alors automatiquement le matériel quand il le faut. Annoncée sous forme de blague le 1er avril, cette version est enfin dispo depuis le 25 juin pour Windows, macOS, Linux et Android.

Maintenant pour ceux qui débarquent et qui ne sont pas très au fait de l'univers de la GameCube, le Game Boy Player c'était un petit boîtier qu'on clipsait sous la GameCube pour jouer à ses cartouches Game Boy Advance sur la télé. En gros c'est une Game Boy sans écran quoi, et ça envoyait l'image et le son à la console et récupérait les inputs de la manette. Nintendo avait même choisi d'y coller une vraie puce GBA plutôt que de coder un émulateur, parce qu'émuler proprement une GBA à l'époque, c'était mission quasi impossible.

Votre navigateur ne supporte pas la lecture de vidéos HTML5. Voici un
<a href="/dolphin-emulator-2606-game-boy-player/dolphin-emulator-2606-game-boy-player-1.mp4">lien vers la vidéo</a>.

Decrazyo vient de sortir ANES , un mod hardware qui transforme votre vieille NES en lui collant un deuxième PPU, la puce graphique de la console.

Résultat, plus de couleurs à l'écran, plus de sprites, et même du parallax scrolling, ces décors qui défilent sur plusieurs plans comme sur les bornes d'arcade. Que des trucs que la petite Nintendo de 1985 n'a jamais su faire, la miskine.

Le hic, c'est qu'il vous faut deux NES pour ça. Une qu'on garde, et une qu'on démonte pour lui piquer son PPU (le fameux RP2C02) pour ensuite le greffer sur la première via une carte maison bardée de logique. Ensuite (et attention, ça devient technique), un démultiplexeur 74LS139 aiguille le processeur vers l'un ou l'autre PPU selon l'adresse mémoire, un latch 74LS373 verrouille les signaux, et 8 Ko de RAM statique dédiée alimentent le second PPU.

En gros, le CPU jongle entre deux cartes graphiques au lieu d'une. C'est tout ce que vous devez savoir.

Pour comprendre pourquoi c'est énorme comme news, faut bien se rappeler les limites de la bestiole. La NES affiche 25 couleurs à l'écran maximum, piochées dans une palette de 64. Et elle ne dessine que 8 sprites par ligne horizontale, d'où le clignotement légendaire des persos quand ça se bouscule (les vétérans de Mega Man voient de quoi je parle). Alors qu'avec deux PPU qui bossent en parallèle, vous doublez le budget graphique d'un coup.

Decrazyo est le premier à reconnaître que personne ne va se lancer là-dedans parce que c'est bien relou à faire. Faut déjà sacrifier deux consoles, sortir le fer à souder, dessouder des puces et se taper du wire-wrap sur une carte prototype. On est dans de la bidouille de l'extrême, celle qu'on fait pour la beauté du geste .

Sauf que, bonne nouvelle les amis, vous allez pouvoir goûter au résultat sans flinguer la moindre console puisque decrazyo a forké l'émulateur Mesen2 pour simuler le double PPU. C'est dispo en build "Dual PPU Mesen 2.1.1" sur Windows, Linux et macOS, Intel comme Apple Silicon. Vous chargez la démo, et vous voyez de vos yeux ce que donnerait une NES dopée.

Ça me rappelle vraiment pourquoi j'adore toujours la scène homebrew NES , 40 ans après. Ces gens sans amis, ni famille (je plaisante, humour, humour, pas taper !) qui continuent de tordre ce hardware dans tous les sens juste pour voir jusqu'où il peut aller, c'est fou ! Les schémas KiCad et le code sont sur le GitHub de Decrazyo , sous licence GPL, si vous voulez fouiller.