La Place des Développeurs dcmsx un décompilateur MSX projet de rétro ingénierie assembleur
Ca va être coton !! 
Je suis loin d'être spécialiste en la question mais m'est avis que tout cela apparaît en données brutes : comment différencier un octet dédié au graphisme d'un autre dédié à la musique ?
Je suis loin d'être spécialiste en la question mais m'est avis que tout cela apparaît en données brutes : comment différencier un octet dédié au graphisme d'un autre dédié à la musique ?
MSX un jour, MSX toujours !
pour le graphisme il faut lire les appels au vdp et voir a quelle adresse ça pointe et combien sur d'octets
pour la musique ça doit faire pareil
il faut donc analyser les appels au bios ou les out un par un pour trouver les zones
connait tu DISZILOG ?
www.msxpro.com/download/diszilog.zip
quand une zone n'est pas reconnue comme du code il le signale
il peux donc y avoir dur texte , données vidéo ou musique a ces emplacements
pour la musique ça doit faire pareil
il faut donc analyser les appels au bios ou les out un par un pour trouver les zones
connait tu DISZILOG ?
www.msxpro.com/download/diszilog.zip
quand une zone n'est pas reconnue comme du code il le signale
il peux donc y avoir dur texte , données vidéo ou musique a ces emplacements
sylvain :
Est-ce que quelqu'un peut m'aider à trouver comment identifier, dans les jeux Konami, les portions de code assembleur associés à la gestion de la musique, des sprites et des graphiques (décors) ?
Ces portions de code ne seront pas facilement identifiables.
Tu peux utiliser au moins 2 critères d'analyse :
1. Identification des appels BIOS correspondants au graphique ou à la musique
2. Identification des accès aux ports I/O correspondants soit au VDP, soit au PSG
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Pour faire ce que tu veux, il faudrait presque émuler le MSX car pour au moins identifier des appels au BIOS, il faudrait connaitre l'état des slots au moment du code à désassembler.
Il y a aussi les accès directs au VDP ou autre puce que l'assembleur doit savoir à quoi correspond chaque OUT/IN rencontré pour en déduire les données (aussi en tenant compte des registres et des instructions de saut du Z80.
Et puis, il n'y a pas que les fichiers binaires ou de Rom qui sont intéressant à désassembler. Il y a ceux du DOS, par exemple.
Il y a aussi les accès directs au VDP ou autre puce que l'assembleur doit savoir à quoi correspond chaque OUT/IN rencontré pour en déduire les données (aussi en tenant compte des registres et des instructions de saut du Z80.
Et puis, il n'y a pas que les fichiers binaires ou de Rom qui sont intéressant à désassembler. Il y a ceux du DOS, par exemple.
il existe une version gratuite de ida, avec ça tu peux désassembler aisément les mégaroms msx.
dis-moi si tu veux ce programme ?
dis-moi si tu veux ce programme ?
Toute matrice carrée sur un corps K, dont le polynôme caractéristique est scindé, est semblable à une matrice de Jordan. Cette réduction est unique à l'ordre des blocs près. De plus, toute matrice carrée nilpotente sur un corps K est semblable à une matrice de Jordan dont chaque bloc est associé à la valeur 0. Évidement, cette réduction est encore unique à l'ordre des blocs près...
voici un aperçu
Toute matrice carrée sur un corps K, dont le polynôme caractéristique est scindé, est semblable à une matrice de Jordan. Cette réduction est unique à l'ordre des blocs près. De plus, toute matrice carrée nilpotente sur un corps K est semblable à une matrice de Jordan dont chaque bloc est associé à la valeur 0. Évidement, cette réduction est encore unique à l'ordre des blocs près...
ida est un peu lourd pour désassembler du prog msx, ce serait cool de faire une mini version de ida rien que pour le msx, ça te dit ?
Toute matrice carrée sur un corps K, dont le polynôme caractéristique est scindé, est semblable à une matrice de Jordan. Cette réduction est unique à l'ordre des blocs près. De plus, toute matrice carrée nilpotente sur un corps K est semblable à une matrice de Jordan dont chaque bloc est associé à la valeur 0. Évidement, cette réduction est encore unique à l'ordre des blocs près...
Très intéréssant projet! ça en est où?
J"avais commencé un peu le même type pour C64 (6502) pour "cracker" les jeux.
Mon programme part d'un snapshot d'émulateur et redémarre l'exécution avec l'état du processeur sauvegardé. Il embarque un simulateur 6502 qui exécute le code du prog pour essayer de déterminer le "type" de chaque adresse mémoire (entre autres...).
Mais une détermination automatique est très difficile, il faut obligatoirement indiquer à l'outil les emplacements mémoire ou se trouve tel ou tel type de données...
J"avais commencé un peu le même type pour C64 (6502) pour "cracker" les jeux.
Mon programme part d'un snapshot d'émulateur et redémarre l'exécution avec l'état du processeur sauvegardé. Il embarque un simulateur 6502 qui exécute le code du prog pour essayer de déterminer le "type" de chaque adresse mémoire (entre autres...).
Mais une détermination automatique est très difficile, il faut obligatoirement indiquer à l'outil les emplacements mémoire ou se trouve tel ou tel type de données...
Rétro coder fou : Z80 : MSX / Amstrad CPC / ZX Spectrum -- 6502 : C64 / VIC20 -- 68000 : Amiga
Mon site dédié à ma passion pour la programmation : http://majikeyric.free.fr
majikeyric :
Mon programme part d'un snapshot d'émulateur et redémarre l'exécution avec l'état du processeur sauvegardé.
Mon programme part d'un snapshot d'émulateur et redémarre l'exécution avec l'état du processeur sauvegardé.
Est il possible de créer un programme qui fasse un "snapshot" du [Color Bus] du VDP ainsi qu'un "Loader"?
L'idée étant de:
1) "Sauvegarder" (dans un premier temps) l'état du [Color Bus] pendant qu'une image y est affichée par une MSX ayant une interface de superimpose.
2) "Loader" (dans un second temps) l'état du [Color Bus] comme si une image y est affichée par une interface de superimpose.
L’intérêt étant d'utiliser la méthode [ Vram Flash Pipeline] sur n'importe quel MSX
L'exploit [Vram Flash Pipeline] permet de charger instantanément en VRAM des images dans n'importe quel mode écran allant du [Screen 0] au [Screen 12].
Plus encore, cette méthode pourrait aussi permettre de charger de la musique WAV en VRAM instantanément ou encore d'autres données instantanément sans solliciter (ou presque pas) le Z80
Edité par igal Le 25/12/2017 à 10h18
Putain ça fait mal 
J'aurais adoré trifouiller les graphismes de space-manbow, remodelé les stage de métal gear 2 pour créer une suite qui colle à la version ps2 etc etc.
J'suis désolé que tout ton travail finisse au placard pour des droits d'auteurs sur des jeux qui ont deux ou trois l'âge de nos enfants
J'aurais adoré trifouiller les graphismes de space-manbow, remodelé les stage de métal gear 2 pour créer une suite qui colle à la version ps2 etc etc.
J'suis désolé que tout ton travail finisse au placard pour des droits d'auteurs sur des jeux qui ont deux ou trois l'âge de nos enfants
Bonsoir,
Je voudrais simplement donner mon avis sur le post de Sylvain. Si il gène où qu'une personne le prend mal (C'est pas le but), il pourra l'effacer sans problème.
Concernant le post de Sylvain :
C'est bien dommage que le projet software sois enterré pour une raison que je trouve un peu bête.
Pour info :
- Quand j'ai fait mon proto MSX2+ (Le NC8+), j'ai modifier la SUBROM alors qu'il y a un copyright sur cette ROM, personne n'a rien dit.
- Quand quelqu'un décompile une ROM ou un logiciel pour le modifier et qui est recompilé ensuite, personne ne dit rien.
- Quand une cartouche hardware et une une cartouche de jeux est refait, personne ne dit rien.
Là, je trouve un peu dommage qu'on lui dise qu'il pourrait y avoir un problème de licence sur son soft. Soit on dit non a tout le monde mais pas a telle ou telle personne.
Ça me fait aussi penser à la personne qui avait proposer une vidéo sur l'aménagement d'un hangar pour en faire un musée. Pour ma part et ça n'engage que moi, je trouve qu'on la un peu envoyer bouler gentiment.
Ma conclusion : Il ne faut pas s'inquiéter si il y a de moins en moins de monde qui se connecte.
Perso, j'ai tellement donné au village ces dernières années (Je parle en idée ou en réalisations) que je suis de moins en moins motiver a proposer quelque chose maintenant. Je trouve même que l'on cherche a démotiver les gens.
Voilà, j'en terminerai là sans répondre aux posts suivant pour éviter toute polémique. Encore une fois, c'est mon avis personnelle.
Je voudrais simplement donner mon avis sur le post de Sylvain. Si il gène où qu'une personne le prend mal (C'est pas le but), il pourra l'effacer sans problème.
Concernant le post de Sylvain :
C'est bien dommage que le projet software sois enterré pour une raison que je trouve un peu bête.
Pour info :
- Quand j'ai fait mon proto MSX2+ (Le NC8+), j'ai modifier la SUBROM alors qu'il y a un copyright sur cette ROM, personne n'a rien dit.
- Quand quelqu'un décompile une ROM ou un logiciel pour le modifier et qui est recompilé ensuite, personne ne dit rien.
- Quand une cartouche hardware et une une cartouche de jeux est refait, personne ne dit rien.
Là, je trouve un peu dommage qu'on lui dise qu'il pourrait y avoir un problème de licence sur son soft. Soit on dit non a tout le monde mais pas a telle ou telle personne.
Ça me fait aussi penser à la personne qui avait proposer une vidéo sur l'aménagement d'un hangar pour en faire un musée. Pour ma part et ça n'engage que moi, je trouve qu'on la un peu envoyer bouler gentiment.
Ma conclusion : Il ne faut pas s'inquiéter si il y a de moins en moins de monde qui se connecte.
Perso, j'ai tellement donné au village ces dernières années (Je parle en idée ou en réalisations) que je suis de moins en moins motiver a proposer quelque chose maintenant. Je trouve même que l'on cherche a démotiver les gens.
Voilà, j'en terminerai là sans répondre aux posts suivant pour éviter toute polémique. Encore une fois, c'est mon avis personnelle.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie