Etant finalement passé sous Windows 7 64-bit tout récemment sur l'un de mes PC (la résistance sous Windows XP ne pouvait durer éternellement), j'ai dû me mettre en quête de solutions pour faire tourner quelques vieux programmes, de l'époque de Win9x, qui fonctionnaient toujours sous XP, mais plus sous Seven en l'état. C'est le cas d'un de mes jeux préférés : SimCity 2000 for Windows 95.

Plus connue dans sous la distribution "SimCity 2000 CD Collection" ("SimCity 2000 Special Edition" en anglais), cette version, bien que datant de 1995, reste à ce jour la plus aboutie, et la plus pratique à jouer sous un Windows ; une version qui rencontre malheureusement des problèmes d'installation sous les systèmes 64-bit, et qui crashe dés qu'on veut charger ou sauvegarder une ville sous n'importe quel Windows sorti après XP (Win7/8/10) 

Et il ne faut pas compter sur la version GOG, qui ne s'encombre pas d'une quelconque mise à niveau, en proposant la version DOS émulée sous DOSBox, en anglais uniquement !...

Passé le problème d'installation, qui se règle finalement assez facilement en copiant directement les fichiers (le dossier SC2K) sur le disque dur, depuis le CD, et en insérant les entrées manquantes dans le registre (voir plus bas), après plusieurs recherches, j'ai fini par tomber sur un patch non officiel qui corrige le problème de plantage lors des chargements/sauvegardes de villes !

Seul problème : il ne fonctionne que sur la version anglaise du jeu ! (si on l'applique sur la version française, celle-ci ne se lance plus du tout, prétextant l'absence d'une DLL). Et étrangement personne n'a eu l'idée d'appliquer ce patch sur d'autres éditions du jeu, sur les versions française ou allemande notamment...
Qu'à cela ne tienne, j'ai ouvert mon éditeur hexa et comparé le fichier original avec le fichier patché, et appliqué la modification constatée (15 misérables octets à modifier) sur la version française du jeu !

Résultat : ça fonctionne !

Un problème de réglé, restait cette histoire d'entrées dans le registre pour mon système 64-bit. Si on trouve un tas d'exemples sur interne (de fichiers .reg à appliquer), ils requièrent une modification fastidieuse de plusieurs paramètres indiquant le chemin d'installation du jeu. Il existe aussi un petit outil automatisant l'installation depuis le CD ("SimCity 2000 installer" par Aldude999), et la création des entrées dans le registre, mais celui-ci ne gère par la langue française pour le moment.
Du coup, j'ai réfléchi à un moyen de simplifier considérablement ce point...

Post complet »

Malgré ce que certains peuvent en dire, FlasKMPEG reste à mon avis encore l'un des meilleurs outils de rip pour les DVD, et ce malgré que la dernière version en date, la 0.78.39, ait déjà plus de 13 ans...

S'il existe bien quelques alternatives, qui feront aussi bien le job, du moins pour ce qui est de réaliser un rip basique de DVD (un film par exemple, sans fioriture -j'ai tendance à passer par le combo DGIndex+AviSynth+VirtualDub pour ça maintenant-), je n'ai trouvé absolument aucune alternative qui autorise comme FlasKMPEG une prise en charge complète de la structure des DVD, par le biais des fichiers .ifo notamment, permettant par exemple de charger un tronçon particulier, lorsqu'on a affaire affaire à plusieurs vidéos (telles que des bonus) comprises dans un même ensemble de VOB, ou d'incruster directement une piste de sous-titres dans la vidéo...

Seul souci, depuis plusieurs années, nombre d'utilisateurs rencontrent des difficultés pour pouvoir l'utiliser, obtenant un vilain message d'erreur lors de son exécution, empêchant d'aller plus loin :

D'après les discussions qu'on peut voir sur le net à ce propos, il semble que ce soit le plugin AVI Out (fichier : aviout.cm.flask) qui pose problème, certains affirmant que cela vient de la configuration (de codecs ?) du PC. En effet, en retirant ce fichier, comme souvent conseillé, le logiciel se lance correctement ; sauf qu'il n'est plus possible d'encoder les vidéos au format AVI, ce qui est pour le moins ennuyeux !
On peut toujours sortir la vidéo dans le format MPEG1 ou 2, mais la configuration est pour le moins laborieuse et implique une conversion intermédiaire, donc une perte évidente de qualité.

Etrangement, je n'ai jamais croisé une réponse pertinente permettant de corriger correctement ce problème, alors que la solution paraît pour le moins évidente : trouver un substitut à ce plugin. Après tout, ces logiciels utilisent généralement des librairies DLL libres, comme FFmpeg pour la plus connue, aussi en cherchant un peu, ça ne devait pas être trop compliqué...
Plus simple en théorie, qu'en pratique, j'ai finalement trouvé la solution dans une parent proche de FlasKMPEG : Xmpeg !

En effet, Xmpeg est un dérivé de FlasK, souvent cité comme une des meilleures alternatives, alors qu'il est pourtant moins performant et ne permet pas une gestion poussée de la structure des DVD. Mais l'important, c'est qu'il fonctionne sur le même principe et utilise un plugin AVI Out (fichier : CM-AVIWriter.prm)  similaire, qui ne pose pas de problème, lui.

A partir d'ici, la procédure est pour le moins simple, puisqu'il suffit de remplacer le plugin de FlasKMPEG, par celui de Xmpeg (donc prendre le fichier CM-AVIWriter.prm, le placer dans le dossier de FlasK, et le renommer aviout.cm.flask, à la place de celui d'origine).

Résultat : ça marche !

Post complet »

Suite au précédent article concernant une avancée avérée en matière de décryptage des jeux SEGA System 32, protégés par Security Chip (Suicide Battery), j'ai pu enfin mettre la main sur le contenu en question pour mon SegaSonic, malgré qu'il soit toujours fonctionnel, et réaliser différents tests afin de livrer des informations bien plus concrètes !

Le temps de me rendre compte que mon Dark Edge, quant à lui, a rejoint le cimetière des jeux "suicidés", en attente d'une greffe d'EPROMs décryptées...

Pour rappel, les jeux concernés sont : Burning Rival, Dark Edge, Dragon Ball Z V.R.V.S., F1 Super Lap, SegaSonic, et The J.League 1994 (Super Visual Football).

Au fil de mes investigations, j'ai donc trouvé des personnes possédant les fichiers décryptés pour Sonic (malheureusement aucun ne possédait les fichiers pour les autres jeux), et l'un d'entre eux a gentiment proposé de m'envoyer un ROMkit (photo ci-dessus), en échange d'une photo prouvant évidemment que je possède le jeu original.

Comme le laissait supposer l'édition phoenix vue sur eBay, les deux EPROMs concernées sont l'EPR-15786C (IC8) et l'EPR-15787C (IC17). Il n'y a apparemment besoin de rien d'autre que les deux EPROMs, pas besoin d'un CPU 68000 de remplacement en l'occurrence pour le Security Chip, comme c'est le cas pour les jeux System 16 (explication plus bas) :

Le résultat est sans appel : ça marche !

Et ceux qui ont suivi se poseront inévitablement la question suivante : "oui, mais si ton jeu marchait déjà avant, comment être sûr ?!"
→ Pour être sûr, j'ai évidemment effectué des tests, avec et sans le module FD1149, pour voir le comportement du jeu, avant et après remplacement des EPROMs. Détails :

Post complet »

Un problème qui parlera aux possesseurs d'Astro City et de New Astro City (voire d'autres bornes) : le câblage du kick harness, pour la gestion des boutons supplémentaires 4-6, variable en fonction des cartes de jeu, lorsqu'on possède un panel 6 boutons (2L12B).

En effet, les Astro ont la bonne idée de proposer un passage de câble, en plus de ceux pour les boutons gérés par le JAMMA (connecteurs AMP UP 12 points), pour la gestion des kick harness, typiquement pour les jeux se jouant avec 6 boutons (exemple : Street Fighter 2 !) ou proposant un câblage un peu bâtard (exemple : Dark Edge), par le biais d'un connecteur AMP UP 10 points.

Il suffit alors côté panel de connecter un câble (souvent référencé comme "extra loom") pour connecter les boutons 4-6 de chaque joueur sur le connecteur AMP UP 10 points, et côté PCB, de réalisation un adaptateur en fonction de chaque jeu ; généralement un ou plusieurs connecteurs de type JST, vers un connecteur AMP UP 10 points.

Sauf que voilà, la borne étant JAMMA+, elle prend aussi de base en charge les boutons 4 et 5 par le biais du peigne JAMMA, ce qui est bien pratique en l'occurrence pour le bouton D sur les jeux Neo-Geo MVS, par exemple !

Basiquement, pour pouvoir bénéficier des boutons supplémentaires sur l'ensemble des jeux, il est donc nécessaire de recâbler le kick harness selon s'il est géré directement par le port JAMMA (limité donc à 5 boutons par joueur), ou par une connectique spécifique.

Post complet »

Quiconque s'intéresse à l'Arcade et aux cartes SEGA ou Capcom a forcément entendu parler de "suicide battery" (pile suicide), ces systèmes dont sont affublés certains jeux, censés empêcher les copies...

Le principe, rapidement :

Certaines EPROMs des jeux sont encryptées, avec une clé de cryptage contenue dans une mémoire volatile (une RAM) alimentée par une pile. Impossible donc de lire la clé dans la RAM en dehors du jeu, à l'instar d'une EPROM, sans risquer de perdre la clé servant au décryptage. Et le problème, c'est qu'une pile ça ne vit pas éternellement, donc le jour où celle-ci est morte, le jeu aussi !

Deux méthodes sont couramment utilisées pour contrer le problème :

• Changer la pile, quand celle d'origine fonctionne encore, par un bricolage parfois périlleux.
  

  • Avantage : l'intégrité du jeu est conservée (dans le cas où le remplacement de la pile sera proprement effectué)
  • Inconvénient : le problème est toujours présent, il est juste retardé
  • Prérequis : de l'adresse, voire du sang froid !

• "Phoenixer" les jeux, en remplaçant les EPROMs cryptées par des versions décryptées.
  

  • Avantage : le problème est définitivement supprimé
  • Inconvénient : pour les puristes, le jeu n'est plus original, puisqu'il a perdu son intégrité
  • Prérequis : il faut que le jeu ait été cracké, et que la clé de cryptage ait été récupérée, ce qui n'est pas chose aisée...

Une nouvelle méthode, prometteuse, est actuellement en cours de mise au point par l'auteur du blog Arcade Hacker, à cheval entre les deux méthodes ci-dessus, mais bien plus consensuelle, puisqu'elle permettrait, au lieu de supprimer la protection, de changer tranquillement la pile (sans craindre de risque de perdre la clé) et de recharger la clé de cryptage ; en clair de "désuicider" le jeu !

Pour l'instant, cela ne concerne que le CPS1 de Capcom (voir vidéos ICI et ICI), et nécessite bien sûr le même prérequis que pour phoenixer un jeu... Le module FD1094 employé sur les cartes System 16 de SEGA est aussi en projet !

Si certains systèmes, parmi les plus connus, comme les System 16 et 18 de SEGA, ou CPS1 et CPS2 de Capcom, ont pour la plupart été "crackés", et ne posent plus réellement de problème de fiabilité dans le temps, ce n'est pas le cas de tous les systèmes... notamment le fameux System 32 de SEGA, qui n'a toujours pas officiellement été cracké, et compte 6 jeux protégés par ce système : Burning Rival, Dark Edge, Dragon Ball Z V.R.V.S., F1 Super Lap, SegaSonic, et The J.League 1994 (Super Visual Football).

Je précise "officiellement", puisque j'ai de bonnes raisons de penser que ce n'est plus le cas aujourd'hui, après avoir déjà croisé récemment deux phoenix editions du jeu SegaSonic, sur eBay et Yahoo Auctions Japan !

Post complet »