krHACKen

Je pense qu'avec mes paramètres de confidentialité, on ne peut pas me contacter sans être dans ma liste d'amis, et qu'on ne peut pas m'envoyer de demande sans être sur un serveur dans lequel je suis. Voilà un des serveurs sur lequel je suis présent : https://discord.gg/m8YzH7 C'est le Discord du forum Darius Saturn. J'y suis connecté quotidiennement, quand mon PC principal est allumé.

Non, toujours pas. Elle se remplit trop vite. J'utilise exclusivement Discord pour les communications privées maintenant. Bien plus simple et plus rapide.

Je ne pense pas que X-Flash arrivera à la reprogrammer. Pendant mes divers tests, je suis tombé sur une cartouche qui n'a pas le même circuit ni le même chipset que la tienne, mais qui a l'équivalent en Texas Instruments de son EEPROM (TMS29F010, IDs 01h 20h). Elle a à peu près le même symptôme. Toggle timeout au premier secteur et un octet corrompu (remplacé par 00h) au tout début de ce secteur (soit à 1F000000h). Bizarrement, la tienne a cessé de terminer ses commandes au secteur 32. J'ai essayé tout ce que j'ai pu dans l'espoir de la reprogrammer avec X-Flash, allant jusqu'à désassembler sa ROM d'origine et EXPAND.EXE, et ajouter leurs flasheurs dans X-Flash en asm. Pas moyen de la reflasher avec X-Flash. J'obtiens toujours un toggle timeout quoi que je fasse. La commande Chip Erase fonctionne par contre. D'où ce que je disais tout à l'heure, il ne vaut mieux pas que j'implémente le Chip Erase avant reprogrammation. Par contre, EXPAND.EXE sera sans doute capable de la reprogrammer. Du moins, il peut reprogrammer la mienne sans erreur.

Amazon c'est mort pour moi. j'ai essayé de valider ma carte, que ce soit sur Amazon DE ou Amazon FR, elle est refoulée. C'est con, autrefois elle était encore acceptée et j'avais acheté un jeu de PS2. Ouais. Il y a sans doute une meilleure méthode pour détecter si l'Xplorer est 2M ou 4M, mais je préfère ne pas changer le code. Vu que je n'ai pas assez de cartouche Xplorer pour tester et que de toute façon, il faut que la détection des Xplorer coexiste sans conflit avec la détection des cartouches non-Xplorer. Donc j'ai laissé le code de détection tel qu'il est et j'ai remplacé FFh par 00h à l'offset 5FFFFh de wipe EEPROM 384k et 512k. Ça semble suffire à détecter les deux chips des FX sans souci. Plutôt que d'écrire un fichier ROM rempli de FFh pour effacer le flash, on pourrait aussi bien utiliser la commande Chip Erase qui est commune à l'écrasante majorité des EEPROMs. Perso je n'implémenterais pas ça. Parce qu'il y a encore des chips que X-Flash ne peut reflasher. Si la commande Chip Erase fonctionne et que l'écriture de la ROM foire derrière, on risquerait de se retrouver avec une cartouche vierge lol. Donc voilà ce que j'ai trafiqué dans le code jusqu'à présent : - Support de la vieille commande Autoselect pour l'obtention des IDs des vieilles EEPROMs SST - Possibilité de changer de ROMFILE dans le menu de sélection des ROMs - Détection auto des cartouches qui mappent les chips avec un trou de 20000h à 40000h - Commutation overburn/normal dans le menu principal - Scan de la zone mémoire allouée au port parallèle et avertissement quand des valeurs changent arbitrairement, avant chaque reprogrammation - Les IDs obtenus via la vieille commande Autoselect sont checké avec la DB des EEPROMs connues de X-Flash, comme avec les IDs obtenus par la commande Autoselect "normale". Aussi, X-Flash affiche les IDs issus des deux commandes Autoselect, ainsi que les deux premiers bytes de la ROM contenue dans la cartouche. Ça permet de voir si les deux commandes échouent, comme c'est le cas avec certaines cartouches (de mémoire, je ne peux citer que la Gamars Movie Card PSX-001). - Le choix entre BL4ZE.DAT/D4TEL.DAT/CAETLA.DAT/OTHERS.DAT/DEVEL.DAT/DEVEL.KHN se fait depuis de menu de sélection des ROMs, avec les touches gauche/droite. Les ROMFILEs .GAP ne sont plus nécessaires, vu que le support des cartouches gappées a été ajouté, donc plus besoin non plus de compiler des ROMs avec 128KB de padding au milieu. DEVEL.KHN n'est que l'équivalent de DEVEL.GAP (contenant le UniROM patché pour les cartouches 2M non-Xplorer), dans lequel j'ai viré les 128KB de padding. - La détection des cartouches gappée semble bien fonctionner. Que ce soit pour les cartouches 2M à une puce de 2M ou à deux puces de 1M. Le flashage est adapté en conséquence (avec un saut de 1F020000h à 1F040000h durant la repro). L'autre avantage, c'est qu'on n'a plus à se coltiner les messages de checking relatifs aux Xplorers quand ces cartouches gappées sont reconnues. - Le overburn est sophistiqué. Il bruteforce la reprogrammation avec différents paramètres, comme le délai entre les commandes, le bus auquel soumettre les commandes, le saut de plage pour les cartouches à gap, la taille des secteurs, les commandes de déprotection... Dans le cas où toutes les combinaisons ont échoué, il tente en ultime recours d'écrire byte par byte (par opposition à une commande par secteur). Le truc que le overburn ne fait pas actuellement, c'est de tester les commandes spécifiques aux cartouches pour le changement/mappage des banks. Pour ça, il y a des profils sélectionnables : Le mode overburn propose 4 méthodes. Celle mentionnée au dessus, la méthode Xplorer FX, la méthode Action Replay Pro 3, et...... le lancement du burner de Nocash (EXPAND.EXE) pour flasher la ROM sélectionnée. EXPAND.EXE est lancé sans patch si les IDs de chips de la cartouche connectée sont dans sa DB. Et avec un patch overburn si ils n'y sont pas. Le patch overburn est basique, comme sur le vieux X-Flash modifié. Il permet de forcer la repro des chips inconnues en assumant que la taille est de 4M. La possibilité d'utiliser le burner de Nocash est probablement ce qu'il y aura de plus appréciable lol. Son soft est génial et c'est un super débrickeur, là où X-Flash se vautre lamentablement. Il faudrait que je fasse plus de tests quand j'aurais le temps, mais j'ai déjà trouvé 3 EEPROMs que X-Flash est incapable de reprogrammer et que le soft de Nocash reprogramme sans problème. J'ai pourtant tenté de reproduire dans X-Flash ce que son burner fait, même en faisant un erase, je ne suis pas parvenu à un tel prodige. À l'inverse, mon Action Replay v2 doté de deux chips de 1M ne peut pas être repro avec EXPAND.EXE. Il ne trouve pas la seconde puce. Vu que EXPAND.EXE n'a totalement rien à voir avec X-Flash, j'ai préféré le laisser en externe plutôt que de le convertir en objet et de le fusionner au code de X-Flash. Histoire de ne pas me montrer accaparant ou ingrat. Si je vais au bout de mon truc et que je ponds ce X-Flash, le binaire EXPAND.EXE original sera à part, sur le CD (je veux dire pas incrusté dans l'exécutable de X-Flash). - Le scan de la mémoire et les warnings qui en découlent ne sont pas utiles pour l'utilisateur lambda. Je pense que je virerais ce machin. Les gens risqueraient de fliper pour rien. Il y a des cartouches ayant des contrôleurs qui foutent des RTC, des rands et autres merdes dans les zones non-allouées au flash (généralement à partir de 1F060000h). Ces cartouches généreront des warnings alors qu'il n'y a pas de défaillance. Donc voilà. Quand j'ai un peu de temps libre, j'allume la PS1 et je bidouille X-Flash. C'est pas les idées qui manquent. Par exemple, je pense que ça serait utile d'afficher la taille des fichiers .rom dans le menu de sélection. Faudra tester, optimiser, nettoyer le code source (qui sera distribué avec la build)... Côté Cheat Engine Compilation, y'aura ça à ajouter : redump.org • Action Replay 2 • Disc 2 redump.org • Interactive Preview Plus: PS2 Launch Guide & Playable GameShark Sampler Peut être ça aussi redump.org • Karat PS PS2-you Pro Action Replay CDX2 • karat PS/PS2??????????????CDX? si le gentleman daigne partager le dump. Puis les éventuelles mises à jour de la codelist avec les widescreen et anti-dithering... Je souhaite finir mes modifs sur X-Flash avant de me pencher sur les tools manquants à Cheat Engine Compilation.

Et pour ce que j'appelle les décalibrations, ce sont les paramètres du bloc optique qui changent de manière inappropriée au fil du temps. Causant des erreurs ou des difficultés de lecture/détection des disques. Une restauration d'un backup.nvm propre (avec LensChanger) quand la console en chie trop pour lire les disques, et ça devrait faire l'affaire, à condition que le bloc ne soit pas crade et la lentille pas abimée. Sans le Romeo Mod, la restauration régulière de la nvram ne donnera pas grand chose de positif, vu que la lentille se détériorera, jusqu'à ce qu'elle cesse de détecter les disques. Donc ouais, on n'est jamais tranquille. Le Romeo Mod ramène quand même bien plus de sérénité et de durée de vie qu'une 50K sans protection. Sans ça et en jouant régulièrement, la lentille finit par claquer. $ONY a été trainé en justice pour ça:DD. Les Mechacon des premières slims (K-chassis) ont des problèmes similaires, mais je n'en sais pas plus sur celles là. Vu que quand j'avais encore une 70004 fonctionnelle, il n'y avait pas de soft pour se servir du JIG. EDIT : De nos jours, les gens ont tendance à ne plus utiliser le lecteur CDVD de leur PS2 lol. Mais sinon pour une bonne PS2 avec un lecteur qui tient la route, comme ça a été dit précédemment, le premier modèle de 39004 (pas les révisions). J'irais même plus loin, une 30004 avec une mobo plus ancienne que la GH-015. Ouais, ça ne sera pas aussi fiable qu'une 39k. Le Romeo préserve la lentille, mais n'empêche pas le Mechacon de bugger comme un dingo.

Ouais. Comme dit précédemment, originaux ou pas, le mechacon poussera la diode à faire un barbecue avec ta lentille. La seule différence qu'il y a entre la lecture des copies et celles des originaux sans mod, c'est la durée de vie. Mais au final, même en ne lisant que des originaux, t'auras à racheter des lentilles. La modif protège le circuit, augmentant considérablement la durée de vie de la lentille, et moyennant des décalibrations. Pour solutionner les décalibrations dues au Mechacon foireux, on peut soit restaurer un backup de la nvram de temps en temps (méthode scabreuse), soit faire tous les réajustements au JIG comme il se doit. L'autre solution pour n'avoir ni dégât optique, ni merdier dans la nvram, c'est d'installer un reset pic. Mais bon, c'est pas génial, vu que son but est de rebooter la console dès que le Mechacon perd les pédales:DD. Concernant ce qu'on peut lire au sujet de la Modbo avec FMCB, ce n'est pas une question de conflit de fonctionnalités. Les puces peuvent empêcher le décryptage MagicGat€. Sorte de parasitage. C'est pour ça que le dev de FMCB et ceux qui touchent aux trucs MG recommandent de l'utiliser sur des consoles non-pucées. Le truc c'est qu'il est impossible que savoir quelles puces interfèrent ni à quel moment ça se produit précisément. Les seuls tests concordants de personnes avec les mêmes puces concernaient le PSBBN. Les gars n'arrivaient pas à lancer de KELFs depuis le navigateur lol. Ça décryptait sans problème le MBR, le lanceur du kernel, mais après ça foirait soit au redécryptage du MBR, soit au décryptage de l'appli. Chez d'autres gars, il y avait des problèmes de décryptage pendant l'installation du lecteur DVD sur la carte mémoire par le biais des CDs d'updates originaux. Ou bien pendant le décryptage des DVDELFs avec HdProjectX du temps où FMCB était en pleine élaboration... Bizarrement je n'ai pas lu des masses de gens se plaignant de plantage de FMCB à cause de leur puce. Je pense que ça doit être OK, et j'imagine que si FMCBInstaller est capable de marier les KELFs à ta carte mémoire en étant lancé dans ta PS2 pucée, FMCB n'aura pas de problème pour booter. En parlant de 50k silver, j'ai remarqué un truc marrant cet après-midi. http://aybabtu.chez.com/PS2/TESTPIX01/stuff.7z Les 50004 silver H-chassis (aka V9) semblent avoir les mêmes ID console & modèle que les 50004 silver J-chassis (aka V11). Si Senyuki passe dans le coin et dump sa I-chassis silver, on pourra voir si $ONY a attribué les mêmes IDs aux silver 50K. Franchement la 50k..... pure daube en série.

Avec PsyQ. En fait j'avais oublié de virer les paramètres d'optimisations lol, ce qui faussait complétement la fonction DelayMs. Ça semble fonctionner maintenant. Mais je n'ai pas testé plus que ça. Faut que je remonte mon PC WinME pour pouvoir débricker la cartouche en cas de pépin. Ouais j'avais vu ça. J'ai rejoins Redump il y a quelques temps et je suis en contact avec la personne qui a partagé ça. Perso je n'ai plus les moyens de m'acheter de cartouches. Et comme t'as dit, les prix des Xploders sont obscènes maintenant. Récemment j'ai corrigé les offsets de l'image disque du Xplorer Expansion CD, pour pouvoir enfin le graver avec mon matos et le tester. De mémoire, ça a upgradé un r2.005 UK en r2.008 UK. J'avais vérifié dans ton fullset et c'était bien une ROM que tu avais archivé. Pas testé avec une ROM US ou JAP. J'ai essayé avec une ROM FR et ça m'avait donné un beau "Cannot change territory". J'imagine donc que c'est un disque UK ne contenant que la ROM UK. ================================ EDIT : Hmmm, je pige pas. La détection postée au dessus est mauvaise. Mauvais IDs, mauvais type d'Xplorer. La j'ai réessayé avec LA MÊME cartouche, et : Là ça me semble exact. Ou bien j'ai encore des problèmes de jus sur ma console à cause du bordel soudé dessus, ou bien X-Flash échoue aléatoirement à détecter le type d'Xplorer. ================================ EDIT2 : Le check de la 2ème bank, qui permet de reconnaitre les FX : int EepromDetect3rdGenFX() { char *Temp,txt[50]; u_char found,xid1,xid2; char *src1 = (char*)0x1F000000; char *src2 = (char*)0x1F040000; int diff = FALSE, ret = FALSE; unsigned long i; for (i=0;(i<0x20000) && (!diff);i++) if ( (*src1++) != (*src2++)) diff=TRUE; if (diff) { WaitScreen("First 3rd gen Xplorer check OK"); Temp = (char*)0x1F045555; *Temp = 0xAA; Temp = (char*)0x1F042AAA; *Temp = 0x55; Temp = (char*)0x1F045555; *Temp = 0x90; DelayMs(100); Temp = (char*)0x1F040000; xid1 = *Temp; Temp = (char*)0x1F040001; xid2 = *Temp; Temp = (char*)0x1F045555; *Temp = 0xAA; Temp = (char*)0x1F042AAA; *Temp = 0x55; Temp = (char*)0x1F045555; *Temp = 0xF0; DelayMs(100); sprintf(txt,"EEPROM %02X %02X",xid1,xid2); WaitScreen(txt); if ( (xid1==SST_ID) && (xid2==SST_29xE020) ) ret = TRUE; if ( (xid1==SST_ID) && (xid2==SST_29EE020) ) ret = TRUE; if (ret==TRUE) WaitScreen("Second 3rd gen Xplorer check OK"); } return ret; } C'est une comparaison des données des deux banks. Si les données sont identiques, X-Flash interprète ça comme un miroir, donc comme un non-FX de 2M (256K) Si les données sont différentes, alors il voit que c'est une capacité supérieure à 2M, et obtient l'ID de la seconde EEPROM. Ce qui veut dire qu'un Wipe EEPROM 512K fausse le check. Vu que le contenu des deux banks sont identiques au final (remplies de FFh), X-Flash y verra une cartouche 2M au lieux d'un FX. Démonstration en vidéo : La solution est de créer une différence de contenu dans les deux banks, en flashant une autre ROM de 2M ou plus petite, et ensuite de flasher la bonne ROM FX. Donc, la reprogrammation de cet Xplorer FX est OK:pouce:. Je vais tester le deuxième FX qui posait problème autrefois. Il a un autre modèle de SST. Je n'ai ni Atmel, ni Winbond chez moi. ================================ EDIT3 : Mon 2ème FX m'a fait un not successful, mais après avoir réessayé, ça fonctionne. Wipe 512, écriture de la dernière ROM FX, écriture de versions FX antérieures, tout fonctionne. Pas d'erreur. Si tu veux tester une build précompilée : http://aybabtu.chez.com/RANDOMPIX/04/xflash_builds_srcs.7z Je n'ai rien trafiqué dans BL4ZE.DAT_xflash-v12-b5.exe. J'ai juste changé le chemin de ROMFILE.DAT pour qu'il pointe vers le BL4ZE.DAT de Cheat Engine Compilation. Ça me permet d'envoyer l'EXE à la console via PSXSERIAL, d'avoir les ROMs de Cheat Engine Compilation, et de ne pas devoir cramer un autre CDR.

J'ai remonté une PS1 avec une puce et une interface SIO pour pouvoir retravailler X-Flash et tester mes EXEs facilement. Donc j'ai compilé toutes les versions de X-Flash sans altérer leur code source, pour voir si elles arrivent à traiter le FX. AUCUNE build n'est parvenue à obtenir les IDs des EEPROMs des diverses cartouches que j'ai testé... http://aybabtu.chez.com/RANDOMPIX/04/snapshot20180417083637.jpg J'ignore d'où vient le problème. Mais le fait est que tous les X-Flash que je compile sont foireux:(.

Ahah , justement je venais pour poster ça. J'sais pas pour l'Xplorer FX, mais en tout cas il serait très facile d'ajouter le support pour les GS/AR v2.x, rendant overburn mod obsolète:pouce:. EDIT : j'ai survolé le src de la dernière bêta. Visiblement il y a une fonction de détection des XP FX...

BluRay masterrace

Toujours le même lien de téléchargement

Liste à jour. Finalement j'ai eu le temps pendant la compression de mes ISOs de finir Cheat Engine Compilation, de monter une PS1 et de le tester. Reste à griffonner un topo des changements, et je pense le sortir aujourd'hui. Ça sera annoncé sur Meta, psxdev et Darius-Saturn.

Merci de m'avoir fait part de ce problème, et pour les updates chez PCSX2. Ouais, y'a des trucs qui m'emmerde avec cette app. Comme l'impossibilité de l'utiliser à un endroit où il y a des espaces dans le chemin. Par exemple, sous XP avec l'app sur se bureau, C:\Documents and Settings\Utilisateur\Desktop\, ça créera le nouveau fichier en tant que C:\Documents, ou un truc similaire. Perso j'ai été contraint de la foutre à la racine de C:\ et c'était chiant pour la création des PPFs. J'ai rejoins des gars de Redump. Il me faut archiver une trentaine de DVDs et peut être un nombre indéfini de CDs après. Donc pour le moment, je ne peux plus rien faire sur ce projet. Mon tool, ma liste et Cheat Engine Compilation ne recevront pas d'update avant longtemps.

Liste à jour. De mémoire j'ai ajouté : "LEGO Racers (UK)" "Road Rash 3D (FR)" "V-Rally 2 (UK)" "Tarzan (FI)" [Disneyn Tarzan (Finland)] "Vanishing Point (UK)" "Vandal Hearts (UK)" "Vandal Hearts (US)" "Vandal Hearts II (UK)" "Vandal Hearts II (US)" "Grandia (FR)" "Grandia (JP)" "Grandia (UK)" "Grandia (US)" "Vigilante 8 (FR)" "Apocalypse (DE)" "Apocalypse (UK)" "Apocalypse (US)" "Monkey Hero (US)" Les codes UK et US de Monkey Hero sont identiques, c'est normal. Aussi, j'ai commencé à faire ANTIDITHERING_PPFs.zip. Des patchs pour les images disques.

C'est possible de fabriquer ça. Mais ça ne parviendra pas à patcher les trucs qui sont en dehors de l'EXE. En fait faudrait coder un mini cheat engine qui s'injecte dans les EXEs pour que tout soit patché même en dehors de l'EXE. Mais sur PS1 on ne peut pas rendre ce type de hack universel. C'est possible sur PS2 parce que la taille de l'en-tête du ELF est modifiable. La plupart des ELFs sont compilés avec une en-tête qui laisse grosso merdo 4096 octets pour une injection de code. Et pour attacher le cheat engine, on utilise une fonction générique du jeu, comme scePadRead ou memcpy. Sur PS1, la taille de l'en-tête est de 2048 octets. On ne peut ni modifier sa taille, ni injecter du code exécutable dedans. EDIT : Les conditions pour convertir un code en patch sont les suivantes : - La cible doit être dans l'EXE - La cible doit être une valeur fixe (comme une fonction), pas un truc variable (comme la valeur de l'énergie d'un personnage) Si les deux critères sont remplis, voilà le calcul à faire : http://aybabtu.chez.com/RANDOMPIX/544084864.JPG Adresse du code - adresse de chargement de l'exe + taille de l'en-tête = offset à patcher Exemple avec le code 30092535 0000 et l'exe du screenshot : 92535h - 10000h + 800h = à l'offset 82D35h du fichier EXE, écrire 00h

Ce truc ne génère pas de code AR/GS, vu qu'il est impossible de savoir à quel offset mémoire les fichiers sont chargé. C'est un patch pour les fichiers extraits d'un BIN+CUE. En gros ça s'utilise comme ça : 1. Extraire les fichiers contenant du code exécutable; 2. Patcher les fichiers avec mon machin; 3. Réinjecter les fichier dans le BIN+CUE. Quand tu donnes un fichier au batch, il crée un fichier patché en ajoutant l'extension .new. Un fichier LOG.TXT est créé, dedans il y a tous les offsets qui ont été patchés. Aussi, le bat fait de la merde si il y a des espaces dans le chemin du fichier. La ligne de commande, c'est FILEPATCHER.EXE input output. Exemple concret : J'ai extrait SLES_015.06, MGS1.EXE, et STAGE.DIR du BIN+CUE du CD1 de Metal Gear Solid FR. Je les ai donné au batch l'un après l'autre. J'ai injecté les fichiers .new dans le BIN+CUE (avec CDmage). Pour résumer à quoi ça sert, c'est pour patcher un jeu sans avoir recourt à l'éditeur hexa. Comme avec le tool E1, les routines complexes avec échanges de registers ou maths ne seront pas traitées.

20180227_FILEPATCHER.ZIP un patcheur de fichiers fait à l'arrache sur la base du tool E1. Testé vite fait avec les fichiers SLES, MGSx.EXE et STAGE.DIR de MGS. Ça semble bien fonctionner. Peut être que cet outil, ou un autre mieux élaboré, serait utile pour créer des patch PPFs... Juste une idée. EDIT : Pour ceux qui ne savent pas en quoi consiste une image disque, si vous voulez patcher directement votre dump avec ce tool, c'est à vos risques et périls. Ce qui est certain, c'est que les ECCs ne seront plus valides. Ensuite l'outil risque de passer à coter de trucs importants, à cause des ECCs qui se foutent en travers du code. Aussi, il y a un gros risque de faux positif en scannant autre chose que du code exécutable. Et de ruiner les infos XA. La méthode la plus propre est l'extraction des fichiers contenant du code exécutable, le patch de ces fichiers, et leur réinjection avec CDmage.

E1_20180227.ZIP Ça me paraissait bizarre qu'il ne trouve jamais rien en valeur OFF. En fait, j'avais oublié d'activer le scan avant la compilation.

Le code "complet" pour MGS FR est dans ma liste. Par complet, je veux dire que j'ai torché le jeu en entier et j'ai créé un code anti dithering à chaque fois que c'était nécessaire. Il reste quand même du dithering à ce stade : quand les bandes noires des cutscenes disparaissent, quand on dégomme des trucs au stinger, et dans la lunette du PSG-1. Le plus gros est patché en tout cas. Ça devrait être jouable sans que du dithering vienne traiter tout l'écran entre deux portes. J'ai séparé les codes du mode VR training, mais ils ne sont pas conflictuels avec ceux du jeu. Concernant l'AR/GS PS1, j'imagine qu'il y a bien trop de codes pour que ça fonctionne. Devrait fonctionner sur les émulateurs, avec d'autres trucs que l'AR/GS.

La PS2 n'a pas assez de patate pour décompresser un CHD en temps réel. Et une fois POPS lancé, y'a plus beaucoup de RAM d'utilisable. Les DMA pour renvoyer les buffers décompressés à IOPCD ne feront que polluer un peu plus l'émulation.

Nope. Pour ce jeu là, faut scanner les dumps de mémoire. L'EXE principal charge des sous-routines depuis d'autres fichiers du disque, selon l'événement. D'où la nécessité de faire des snapshots avant les gros chargement de données. EDIT : dans une moindre mesure, c'était aussi le cas des Gran Turismo, qui ont d'autres EXEs planqués quelque part. EDIT 2 : Et j'imagine que ça serait la même chose sur Klonoa...

J'y jetterais un œil. Peut être qu'il y a une protection, mais je n'ai pas vu de mastercode dans ma liste... Liste actualisée : "Tomb Raider (DE)" "Tomb Raider (FR)" "Tomb Raider (UK)" "Tomb Raider (v1.0 US)" "Tomb Raider (v1.1+ US)" "Tomb Raider 2 (FR)" "Tomb Raider 2 (DE)" "Tomb Raider 2 (IT)" "Tomb Raider 2 (JP)" "Tomb Raider 2 (UK)" "Tomb Raider 2 (US)" Les codes de TR1 US sont les mêmes pour toutes les versions. Les codes de TR2 US sont les mêmes pour toutes les versions. Il y a un "Tomb Raider (Platinum) (UK)" dans la liste avec des codes de triches différents. Je n'ai pas créé de code anti-dithering pour cette version parce que je ne l'ai pas. Mon code a été créé pour celui redumpé. J'ai modifié le code de MGS FR. Il est très loin d'être complet. C'est l'enfer, je vais devoir torcher le jeu en entier, en faisant des snapshots partout, en visionnant toutes les cutscenes et en faisant attention au moindre détail. Un descriptif des codes qui sont dans la liste : EDIT : Oh, en rematant tes codes pour Tenchu 2, j'y repense. Tes codes, tu les mets à l'identique dans CEP ? Si c'est le cas, c'est peut être de là que vient le problème. La description du code est à mettre en haut du code, pas à la suite sur la même ligne. En fait dans la liste que tu as posté, tous les codes D sont annulés. CEP ignore le code si il y a des caractères invalides sur la même ligne. C'est pour ça que j'ai changé mon outil pour qu'il mette la description en haut des codes.

Aussi, concernant CEP. Les changements dans l'onglet Cheat ne sont pas effectifs en temps réel. Après avoir modifié/ajouté/supprimé un code, faut faire OFF puis ON pour que les changements s'appliquent.

Après avoir fait reset and run et cliqué sur la fenêtre du jeu pour que le jeu se lance, faut cliquer sur Search pour que CEP s'attache au processus. http://aybabtu.chez.com/RANDOMPIX/2542054.jpg Tu verras qu'en face de NO$PSX.EXE, CEP te donnera une autre base address (c'est "013E0100" sur ma capture d'écran). Une fois que tu as cette nouvelle base address, tu peut la mettre dans APPLIST.TXT (no$psx v2.0 with Debugger | NO$PSX.EXE | BASE_ADDRESS | $00200000). Et normalement après avoir fait cette modif, tu n'auras plus besoin de cliquer sur Search à chaque fois que tu relances no$psx. Je suis entrain de réexaminer MGS. En plus du dithering présent dans le codec que tu avais remarqué, il y a du dithering quand tu rampes dans une canalisation (j'ai vu ça dans cette qui va à la cellule du chef du DARPA, et ça affecte également la cutscene). Les cutscenes où le Metal Gear apparait ont aussi du dithering. J'aimerais trouver toutes les adresses nécessaires à patcher, parce qu'il y a une chiée de résultats. Ça serait bien d'en éliminer... EDIT : J'en ai fini avec les codes pour TR 1 et 2. Je foutrais la liste en ligne une fois que j'en aurais terminé avec MGS.

Bugfix : http://aybabtu.chez.com/kHn/E1_20180224.ZIP