Comme l'a écrit Markerror, il te faut une bonne maitrise du z80a, disposer d'un assembleur/désassembleur, et avoir de la patience.
Les émulateurs te permettent de faire les choses plus facilement aussi, puisque tu peux faire fonctionner le z80a instruction par instruction... Mais c'est moins amusant... 
Je ne suis pas certain qu'on puisse écrire des kilomètres sur le sujet, sans que ce soit rapidement très rébarbatif et basé sur des analyses de code et listing sans fin.
Ce que je peux te dire sur le sujet... 
Il y avait 2 méthodes assez différentes.
Certains utilisaient une interface (type Hacker ou Multiface II) pour aller "plus vite" et s'affranchir de pas mal d'étapes. 
D'autres partaient de zéro, sans aide matérielle. 
Pour lancer un jeu sur CPC, tu n'as pas cinquante façons de le faire. 3 au total.
Via un RUN"xxx", un LOAD"xxx" (cas extrêmement rare), ou l'instruction "|CPM" (sur disquette)
Pour la première méthode (RUN) Le CPC est capable de sauvegarder un fichier basic en mode "protégé"
Ce qui signifie que le programme est effacé de la ram si l'interpréteur de commande basic démarre (arrêt du programme (break) ou load"xxx"). Ca se contourne assez facilement, en déviant le break avant le load"xxx".
Il faut pour ça mettre sur le vecteur firmware du break le petit code suivant : org &bb48 / ld a,0 / ld (&Ae2c),A / ret
Lorsque le programme basic est "déprotégé", il faut regarder ce qu'il fait.
En général, il peut charger un programme en langage machine (ce qui peut aussi être fait directement via un RUN"yyy")
Tout programme sauvegardé en binaire est chargé à l'adresse à laquelle il était en mémoire (avec un RUN"yyy" sans paramètre)
Il est exécuté à une adresse qui a été indiquée lors de la sauvegarde (qui n'est donc pas forcément identique à l'adresse du début, mais de préférence dans le code chargé...).
Pas mal d'outils permettent d'analyser le "header" d'un fichier binaire pour voir son adresse de début, sa longueur et son adresse d'exécution. Lorsqu'un programme est chargé via l'instruction "CPM", le premier secteur système de 512 octets de la piste 0 est chargé en #100 et exécuté à partir de cette adresse (c'est un code présent dans la rom 7 qui fait ce boulot). Il suffit donc de charger le code binaire sans l'exécuter et analyser ensuite ce qu'il fait.
(lire un secteur nécessite de connaitre un peu le firmware de la rom disque ou de connaitre le fdc 765)
L'objectif est donc toujours de charger le code sans l'exécuter pour l'analyser.
Cette analyse conduit toujours plus ou moins facilement à obtenir un code capable de vérifier le support physique dans le cas d'une disquette et à faire un "reset" si il s'agit d'une copie (certaines données entre les secteurs étaient réalisées avec des machines professionnelles, souvent non reproductibles avec le 765 du cpc). C'est cette routine qu'il faut "éliminer" pour que la copie fonctionne.
Parfois, certaines protections étaient plus "sournoises" et laissaient le joueur avancer avant de le bloquer par un message. J'avais vu ça par exemple sur un jeu d'aventure qui débute dans une maison avec un "chat noir" à la gaston lagaffe (je ne me rappelle plus le nom) qui affichait en boucle un message arrivé à un certain niveau du jeu (qui impliquait d'avoir avancé un peu dans le jeu). L'auteur de la protection n'avait pas été bien malin, car il n'avait pas prévu de mettre un "reset" en cas de copie afin qu'un cracker le trouve et considère le "job fait". Il était donc étrange qu'un jeu ait un format disque bizarre sans qu'il y ait une protection quelque part. En général, beaucoup de "crackers" ne jouaient même pas aux jeux qu'ils avaient craqués.
Cette méthode a cependant eu le mérite de "ralentir" la diffusion du jeu et de frustrer les "non cracker" qui devenaient de potentiels acheteurs (doute  ). Il aurait été bien plus malin de laisser croire un jeu déplombé, et de provoquer, après un certain délai de jeu, des crash variables, mais je ne pense pas l'avoir jamais vu.
Les jeux étaient souvent stockés directement comme des secteurs (parfois très différents du standard amsdos). Pour des raisons de coût de disquettes et de rapidité de copie, les crackers remettaient les jeux en format amsdos en remettant ces groupes de secteurs décryptés sous format Amsdos. La majorité des jeux d'action étaient composés de 3 fichiers. Un loader, un écran et le jeu, et donc le gain de place était intéressant. Un format "standard" était aussi bien plus rapide à dupliquer car il ne nécessitait pas d'analyse "discologique".
Les choses étaient plus complexes avec des logiciels ayant recréé leurs propres routines disque et chargeant des images et/ou levels constamment mais cela présentait surtout un défi intellectuel si la disquette était déjà utilisée complètement (sauf à "faciliter" la rapidité de copie...).
Pour les cassettes, c'est le niveau d'enregistrement qui constituait la protection (pour empêcher la duplication), et pour générer une sauvegarde il fallait pouvoir empêcher le programme de démarrer pour faire une sauvegarde à partir du cpc.
La suite est de l'analyse de code z80 assez pointue (par exemple fonctionnement du registre R), combinée à la connaissance de l'architecture de la machine (commutation des roms, ram, connaissance des circuits, notamment le contrôleur de disquettes). Les auteurs de protection déployaient beaucoup d'imagination pour tromper leur monde. Il est impossible de décrire une technique en particulier. Une des plus connues consistait à enchainer de multiples décrypteurs de code (souvent réalisés à base de l'instruction xor qui est non destructive (contrairement à and ou or)), et ce à l'aide d'une clef plus ou moins liée à la routine de décryptage (protection speedlock par exemple). Si tu cherches sur ce forum, tu devrais pouvoir retrouver un thread sur la protection de Hercule, ou la protection a été "dénudée" étape par étape. Je crois que d'autres protections ont également été analysées.
La protection présentait parfois plus d'intérêt que le jeu qu'elle protégeait (notamment celle du jeu Nécromancien, qui a été réputée être une meilleure protection créée sur cpc). Rémi Herbulot, auteur bien connu de "Crafton & Xunk", "Macadam Bumber", .. avait également créé une bonne protection dont la faiblesse résidait surtout dans sa "vulgarisation" à tous les jeux édités par Ere Informatique, puisqu'elle "déviait" les LOAD du firmware pour permettre à des jeux en basic de l'utiliser.
A condition de disposer d'un bouton de reset hardware, et sachant que peu de softs Cpc (notamment les jeux) ont exploité les 128k, il est aussi possible de configurer le cpc pour qu'ils fonctionne avec la 2ème page de 64ko en lieu et place de la première page (out &7F00,&C2 en ayant pris soin de dupliquer l'intégralité des 64k principaux dans la deuxième page). Le code pour passer dans ce "mode" est simple et cela permet de lancer un jeu (en tapant en aveugle car on ne peut rien "voir" sur l'écran, car le CRTC affiche uniquement les données de la première page). Un reset hardware permet de récupérer le contenu de cette seconde page puisqu'il commute la ram principale, et la rom du Cpc ne touche pas à la mémoire complémentaire, qu'il suffit ensuite d'aller récupérer (mais ce n'est pas du tout une méthode propre, assimilable à du crack par cartouche... )
D'ailleurs, et c'est un autre sujet qui n'a rien à voir (je profite de cet interlude sur le swap 64k  ), mais j'ai souvent lu, de manière récurrente, à droite et à gauche, que beaucoup sont emmerdés lorsqu'ils veulent obtenir un écran overscan en restant en basic, car il faut forcément déborder sur une zone "système" avec perte de 16k du basic. Il est cependant parfaitement possible de ne pas perdre 1 seul octet de la ram centrale, en swappant et déviant certaines fonctions du système pour qu'elles "basculent" sur la page principale pour certaines fonctions vidéo. C'est dit.
Bon courage
|
).