Necstasy

Bonjour!

Ca va faire une éternité que je n'ai rien écrit sur ce forum. Alors pour me faire pardonner voici le source du désassembleur maison que j'utilise pour mes tests. Ca m'a permis de comprendre un peu mieux comment étaient organisées les roms pce et aussi pour ripper 2/3 bricoles

https://github.com/pce-devel/Etripator

Je n'ai pas mis de lien direct vers l'exécutable pour éviter d'éventuelles catastrophes Mais il est néanmoins dispo. Donc comme le dit si bien le commentaire au début du source (d'ailleurs il y a une faute dedans...):

Utilisez ceci à  vos risques et périls! Je dégage toute responsabilité en cas d'explosion de votre animal de compagnie!

D'ailleurs n'hésitez pas à  enrichir/modifier/débugger ce truc. J'avais pensé rajouter des options de ligne de commandes (pour par exemple ne désassembler qu'une zone précise de la rom). Donc si quelqu'un se sent d'humeur téméraire, il est le bienvenue.

Merci MooZ. Je n'oserai certainement jamais m'en servir mais je suis sur que ca pourra etre utile a certaines personnes ici

Merci MooZ pour ce petit utilitaire.
La scene Nec Française rules !!

... Red ...

Faut dire que ça a pas été le public le plus mal loti en matière NEC ! Je dirais même le mieux loti après le Japon et avant les USA.

C'est bien mais ça marche comment ?

cosmos99 a écrit :C'est bien mais ça marche comment ?

Je ne suis pas sure que ce programme soit fait pour toi cosmos mais pour commencer tu peus te renseigner sur la compilation d'un programme en C...

Et pour ceux qui n'aurais pas compris à  quoi sert ce fichier, il vous permet de desasembler un jeu PCE, interessant si vous connaissez l'assembleur du 6502...

Concretement on peut extraire les images, les sons ?
Remplacer les textes ?

Je pose ça comme ça car j' connais rien en programmation (j'ai arreté en 1987 après avoir passé un samedi après-midi à  recopier un programme en basic sur amstad proposé dans un mag !! C'était minable, ça s'appelait "le pisseur du val")

J'aurais aimé voir à  quoi ressemble une rom mais je ne sais pas comment faire....

Woops!

Je savais que j'avais oublié quelquechose

etripator.exe maRom.pce dumpDeMaRom.txt

Ca ne peut malheureusement pas encore extraire les données. Il faudrait pour cela analyser le code pour detecter les endroits où on fait des lectures en ROM. Ce serait plus un debugger qu'il faudrait (comme celui de mednafen), ou sinon intégrer un mini emulateur.

Merci MooZ, trés bonne idée que je vais m'empresser de compiler

Concernant la position des données (graph son ou map) a l'interieur de la rom, la tendance majoritaire de la plupart des machines 8bits,et cela inclus la nec, est de les stocké sur des pages separés de celle du code (suivant la machine et le compilateur utilisé, on a méme pas le choix).

Sur nec,une page faisant 8Ko, on peux avoir par exemple pour un jeux de 128Ko:

de la page 0 à  3: 32 Ko de code
de la page 4 à  7: 32 Ko de map
de la page 8 à  15: 64 Ko de graph

C'est rarement aussi simple que ça, mais je pense que cela donne un indice sur la façon dont le code et les data sont séparés, toujours en respectant une page de 8Ko.

Bon c'est pas grave.... oubliez moi.... de toute façon c'est du chinois votre truc !

Bon, voilà  ce que je vais faire pour l'instant :
* faire une petite danse ridicule
* Récuperer les addresses des différents vecteurs d'interruptions. Ces derniers se trouvent
à  partir de l'offset $1ff6. On a dans l'ordre IRQ2, IRQ1, TIMER, NMI et RESET.
* Désassembler à  partir de ces addresses et m'arreter dès que je vois un rti, un rts, ou un bra.
* Sortir un xml ou un truc dans le genre pour pouvoir désassembler finement la rom. * Sortir un fichier par section de code/donnée lu/trouvé. Et le reste est sorti en forme désassemblé et brut.

Après il ne reste plus qu'à  lire tout le code désassemblé et modifier le xml/fichier de conf pour y inclure les nouvelles sections de données/code.

Vous en pensez quoi?

Après une profonde réflexion de 5 minutes, je propose le xml suivant: hum.... On pourait presque utiliser un bon vieux csv des familles...

Ai! J'ai quitté l'école y plus de 10 ans, alors en dehors du C du pascal et de l'asm, je pige rien au language plus "moderne".

Tu peux l'ecrire en algo informel, histoire que je comprenne

NB, IRQ2 est rarement utilisé pour les jeux cartouche, elle est partagé entre l'instruction BRK (possibilité d'interruption logiciel) et le decodeur ADPCM (uniquement présent sur les machine CD).

NB bis: j'ai ecrit en C y a pas mal d'année un decodeur graphique pour la nec, tous les element graphique sont codé sur 4bits (16 couleurs) mais hélas pas de façon linéaire (pense au vieux mode X du pc si tu connais), j'essairais de retrouvé ça.
Le seul aspect ennuyeux quand on dumpe des graph directement de la rom, c'est qu'il n'y pratiquement aucune chance de retrouvé la bonne palette

ben en gros c'est juste un fichier de conf disant où commencent et s'arretent les sections de données et de code.
Sinon le problême avec les données graphiques, c'est qu'il y a deux types d'encodage. Pour les sprites, l'image est découpée en bloc de 16x16. Le premier octet correspond au premier bit des 16 pixels de la première ligne et ainsi de suite pour les 3 bits restants et les 16 lignes restantes. Par contre pour les blocs du décor (tile), l'encodage est un peu plus balaise. Là  les images sont découpées en blocs de 8x8 et les lignes sont entrelacées. Les 2 premieres octets contiennent respectivements les premiers et seconds bits des 2 premieres lignes. Les 2 octets suivants, les 2 premiers bits des 2 lignes suivantes etc... jusqu'à  la 8eme ligne. Et on recommence avec les bits 2 et 3.
... Je crois que c'est mieux expliqué dans la TGhack faq (avec des schémas en ascii et tout... et j'en vois 2 aux fond qui saignent des yeux).

Sinon, je pense sortir une nouvelle version du désassembleur au courant de cette semaine.