APPLICATIONSCOURS DE BIDOUILLAGE ★ JOYSTICK n°7 - Cours de Bidouilles ★

Patrice Maubert - Cours de Bidouilles - Joystick N07Applications Cours De Bidouillage

Salut les kids. Alors c'était comment le BAC ? Non, si je vous pose cette question, ce n'est pas pour vous mettre mal à l'aise, mais plutôt pour me mettre à l'aise parce que vous, vous l'avez passé (sauf nos amis Carine et Nicolas qui sont trop jeunes ou trop cancres, allez savoir. . . ) mais à l'heure où j'écris ces lignes ce n'est pas encore mon cas, donc je défoule mes angoisses en vous les racontant. Ca vous embête pas trop? Si ? Bon alors parlons plutôt bidouilles. En effet, en ce déjà quatrième épisode de la saga, il serait temps de faire un bref. . .

RESUME DE LA SITUATION

En effet, il serait bon de rappeler, pour les lobotomisés qui n'auraient pas tout suivi, ce qui s'est passé depuis le premier épisode. Nous avons vu, da"ns l'ordre, comment changer le nombre de vies d'un jeu, en recherchant la chaîne 3E XX 32, XX étant le nombre de vies, que l'on peut remplacer par ce que l'on veut. Ensuite, nous avons vu une autre méthode, qui est de rechercher les 36 XX, et encore une fois de modifier le XX. Ces recherches vous permettent de repérer quelle est la case mémoire des vies, que nous noterons XXYY, et de trouver les autres endroits où elle est appelée, en recherchant simplement YY xx, ou plus précisément 32 YY XX pour de l'adressage direct, ou 21 YY XX pour de l'adressage indirect. Vous avez alors fait le repérage de la décrémentation. Le dernier stade consiste bien évidemment à enlever cette décrémentation, qui se manifeste le plus souvent par un 3D (=DEC A en assembleur) dans le cas de l'adressage direct, ou par un 35 (=DEC (HL) en assembleur) dans le cas de l'adressage indirect. Quand je parle "d'enlever" ou, plus trivialement, de "virer" un octet, je rappelle qu'il s'agit bien sûr de remplacer sa valeur par un 00 sous l'éditeur (de DISCO ou autre), puis de réécrire le secteur où il se trouve. Il est bon parfois de rappeler les évidences. . . Autre évidence que je n'ai pas rappelée depuis un certain temps, c'est qu'il faut éviter, lorsque vous travaillez avec un éditeur de fichiers, d'effectuer les changements directement sur un original. Et il ne faut jamais oublier de noter l'emplacement et la teneur exactes des changements effectués. Car le remplacement d'un grand nombre d'octets significatifs par des 00 rendrait à jamais introuvable par recherche la zone en question. Donc prudence !

Pour terminer ce résumé, disons que nous avons vu jusqu'ici tout le cheminement du travail. Tout le reste consiste à examiner les subtilités, les cas tordus, les exceptions, etc. . . Mais c'est la l'essentiel du savoir d'un bon bidouilleur, qui ne consiste pas seulement a avoir une méthode générale, mais qui est surtout la somme d'innombrables expériences sur des jeux divers.

QUESTIONS , REPONSES :

Je voudrais ici répondre à deux questions que l'on me pose souvent. La première est.' comment installer un poke avec le HACKER ? Non monsieur Danbiss, vous avez perdu, ce n'est pas la bonne réponse. Vous êtes viré. La bonne réponse était .' c'est impossible. On ne peut pas installer un poke avec le HACKER, sauf à de rares exceptions, trop particulières pour être évoquées ici. Vous avez tous remarqué que le HACKER possédait une instruction dénommée POKE, mais lorsque vous l'avez utilisée, vous ne savez pas comment relancer le jeu. Et bien moi non plus! On ne peut pas, parce que le HACKER, lorsque vous l'activez, ne conserve pas toute la mémoire. Il efface en particulier l'écran, que vous ne pouvez pas récupérer, mais il efface aussi d'autres zones mémoires, plus précisément de &0000 à &003F, et de &B100 à &FFFF. Et même si ces zones ne servaient pas au programme, il ne conserve pas l'adresse du PC, c'est-à-dire l'adresse où en était l'exécution du programme, ni aucun autre registre, ni les couleurs, ni la configuration hardware de l'écran, ni l'état d'interruptions, ni les connections des ROMS, ni...

Enfin bref, relancer un programme devient vite mission impossible. Je précise que la MULTIFACE conserve toutes les données précitées. Alors que faire? Dans JOYSTICK, les bidouilles sont généralement données sous deux formes. Un POKE et une recherche. Lorsque vous avez le POKE, vous pouvez désassembler avec le HACKER autour de l'adresse de ce POKE, noter les cinq octets autour du POKE, et vous obtenez alors une formidable recherche que vous pouvez, après l'avoir passée deux minutes à feu doux, rechercher avec DISCO.

L'autre question est.' Comment peut-on convertir les adresses données par DISCO en édition de secteurs, qui vont généralement de 0000 a 01FF, et qui reviennent à zéro chaque fois qu'on change de secteur, en adresses absolues en mémoire de 0000 à FFFF ? Bonne réponse monsieur Danboss, c'est effectivement impossible, vous êtes nommé à la place de monsieur Danbiss, récemment viré. L'adresse que vous donne DISCO est l'adresse de l'octet dans le secteur où il se trouve, donc une adresse entre 0000 et 01FF, DISCO éventuellement plus. Pour savoir à quoi cette adresse correspond, il faudrait savoir où le secteur sera chargé en mémoire. Si le secteur fait partie d'un fichier, il faut connaître l'adresse de chargement de ce fichier, et quelle est  la position du secteur parmi l'ensemble des secteurs composant le fichier. En bref, c'est bien trop compliqué, et c'est pourquoi DISCO ne vous donne que l'adresse dans le secteur. Si vous êtes l'heureux possesseur d'un HACKER, vous pouvez noter les autres octets autour de l'octet, ce qui vous donne une zone que vous pourrez rechercher avec le HACKER, qui vous donnera alors la véritable adresse en mémoire après le chargement du jeu. Si vous avez une MULTIFACE, vous pouvez vous procurer l'INSIDER, qui donne à votre MULTIFACE des options de désassemblage et de recherche, absolument atroces à manipuler, mais bon on ne peut pas tout avoir.

SOUS LES DRAPEAUX ON DEVIENT vite FLAG-ADA

( ce paragraphe est dédié a notre missile préféré)

Peut-être vous est-il déjà arrivé, en enlevant une décrémentation, d'obtenir le résultat suivant. Le jeu affiche un  flamboyant 'GAME OVER', dès la perte de la première vie. Et vous vous êtes alors dit . « Beh mince alors, c'est sûrement pas la bonne décrémentation, faut qu'j''regarde plus loin. » Eh bien vous aviez tort, parce que c'était justement la bonne. Considérons la suite d'instructions suivante .'

LD A, (CASE)
DEC A
JP  Z, GAMEOVER
LD (CASE), A

Le programme décrémente le nombre de vies, et si celui-ci est nul, effectue un saut ( =JP=JUMP ) à la partie du programme qui affiche 'GAME OVER', et tout le reste. Le fait d'effectuer la décrémentation affecte ce qu'on appelle un flag (drapeau en français, d'où le jeu de mot crétin qui introduisait ce paragraphe). Ici le flag Zero, qui est mis si l'instruction DEC A provoque la mise à zéro du registre A, et sinon le flag est annulé (mis à zéro si vous préférez). Le JP qui suit est un saut conditionnel, qui ne se fait que si le flag Z ( Zero ) est mis. Mais maintenant. imaginons que vous enleviez l'instruction DEC A. Il Y aura donc à la place un NOP ( qui signifie No Operation, pas d'opération ), qui n'affecte en rien les flags, et laisse donc le flag Z dans son état initial. Et allons encore plus loin, imaginons que dans son état initial, ce flag était mis (par la partie de programme qui précédait). Le nombre de vies reste le même, la décrémentation n'est pas effectuée, mais le saut conditionnel se fait tout de même, car le flag Z est mis C'est pourquoi vous constatez la fin de la partie des la perte de la première vie.

Quelle est la solution ? Tout simplement, remplacer le DEC A par une instruction qui n'affecterait pas le contenu du registre A, tout en affectant les flags, et dans le bon sens. Cette bête rare s'appelle AND A, elle donne en langage machine A 7, et elle s'appelle un opérateur logique. Je ne détaillerai pas ici son fonctionnement parce que ce n'est pas un cours d'assembleur. Voila qui règle le sort des 'GAME OVER' intempestifs en adressage direct, mais qu'en est-il pour l'adressage indirect, dont je le rappelle, l'instruction de décrémentation privilégiée est le DEC (HL), qui donne en assembleur 35. Eh bien il suffit de le remplacer par un AND (HL) ( logique non ? ), code en assembleur par un A6. Remarquez qu'il aurait également été possible de virer l'instruction JP Z, GAME OVER, mais cela aurait fait trois octets à enlever, et je suis très fatigué en ce moment alors. . . Donc on résume. si votre bidouille donne un GAME OVER dès la première vie perdue, au lieu de remplacer par 00, remplacez les 3D par des A 7, et les 35 par des A6.

PLUS DE PLACE !!!

C'est le moment de se quitter. On se retrouve non pas dans un mois, mais à la rentrée, avec encore plus de bidouilles. Je vous rappelle que vous pouvez vous aussi me faire part de vos angoisses (informatiques de préférence) sur 3615 JOYSTICK en bal MAUBERT (c'est moi). Et je ne vous quitterai pas sans vous avoir souhaité de bonnes vacances à tous, en compagnie j'espère de votre magazine préféré. . .

Atchao bonsoir,

PATRICE MAUBERTI, JOYSTICK n°07 JUILLET AOUT 1990, page 83

★ LICENCE: COMMERCIALE
★ ANNÉE: 1990
★ AUTEUR: PATRICE MAUBERT

Page précédente : Patrice Maubert - Cours de Bidouilles - Joystick N06

CPCrulez[Content Management System] v8.75-desktop/c
Page créée en 051 millisecondes et consultée 1002 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.