Même si le jeu fonctionnait parfaitement, Mathieu était quand même inquiet vis à vis de la possibilité de suicide de sa plaque.
De plus, les textes in game étaient en japonais, ce qui empêchait la compréhension de certaines questions cruciales présentes vers la fin du jeu.
Il existe déjà un set décrypté chez retroclinic, disponible en version anglaise d'ailleurs, mais ce dernier emploie des eproms de taille doublée par rapport à l'original (64Kb au lieu de 32Kb), et il nécessite de faire des modifications physiques sur la carte pour être utilisé.
La raison du doublage de capacité des eproms est simple, et c'est d'ailleurs le même principe qui est utilisé dans les versions bootlegs du jeu : en gros, les roms programmes sont cryptées, mais de façon différente selon que ce soit des opcodes ou des données.
<aparté technique>
Avant d'aller plus loin, faisons un petit peu de théorie : les opcodes sont les instructions de bas niveau permettant de programmer un processeur en utilisant un langage qui s'appelle l'assembleur. C'est le langage de plus bas niveau (appelé aussi langage machine).
Chaque processeur a ses propres opcodes (et donc son propre assembleur), ce qui oblige à réapprendre le fonctionnement à chaque fois.
Par exemple, dans le cas du Z80, l'instruction ADD HL,BC ajoute le contenu du registre BC au registre HL. L'opcode correspondant à cette instruction est 09 (en hexa). C'est une intruction simple : un seul octet, et pas d'opérandes/données.
L'instruction JP nn permet de faire un saut dans le code afin d'exécuter l'instruction dont l'adresse est spécifiée par nn. L'opcode correspondant à cette instruction est C3 XX XX. Elle se compose de l'opcode (C3), puis de 2 octets variables spécifiant l'adresse de destination du saut. Ces deux octets correspondent aux données de l'instruction.
Chaque instruction du Z80 fait entre 1 et 4 octets en taille, celle de l'opcode varie entre 1 et 3 octets, et celle des données entre 0 et 2 octets.
</aparté technique>
(j'ai comme l'impression d'avoir perdu 99% de mon lectorat
)Si nous revenons à nos données décryptées évoquées plus haut, et au fait qu'elles fassent le double de la taille des données encryptées, l'explication est simple : le code original a été décrypté complètement une première fois comme si c'était des opcodes (la partie basse de l'eprom doublée), puis une deuxième fois comme si c'était des données (la partie haute de l'eprom doublée).
Ainsi toutes les données décryptées sont présentes dans l'eprom doublée, et la modif physique de la pcb permet de sélectionner soit les opcodes soit les données correctes dans la rom à l'exécution.
Le Z80 d'origine lui décrypte les opcodes/données à la volée.
Je pense qu'il est possible de tout faire rentrer dans une eprom de 32Kb, un peu de la même façon que ce que j'ai fait pour les FD1094.
Le principe serait de remplacer directement dans la rom d'origine les opcodes cryptées par leur version décryptée, et de faire la même chose pour les opérandes/données, la difficulté étant de faire la distinction correcte opcode/données pour chaque instruction.
Liste des choses à faire :
1) Développer un petit programme reprenant les routines de décryptage du MC8123 contenues dans Mame
2) Ajouter à ce programme la détection du format des opcodes
3) Décrypter ensuite les données encryptées en utilisant la détection du point 2
4) Générer automatiquement les fichiers binaires à partir des données décryptées
5) Compiler une version spécifique de Mame pour tester les fichiers générés
6) Tester sur le vrai hardware
7) Rendre le programme générique afin de pouvoir décrypter les autres sets encryptés à base de MC8123
Bon, ben y a plus qu'à
, je vais le suivre avec la plus grande attention. Merci encore pour tout
Anciennement 
), et j'avais eu des résultats catastrophiques (je me souviens d'un 4/20 à un examen 
), je n'y trouvais aucun intérêt à l'époque ... mais ça fait quelques années que j'ai changé d'opinion 
pas bien du tout)
.