Gens KMod++
Posted: Thu Sep 15, 2011 6:10 am
My french writing skill suck and I really think my english skill are not better. Shame on me... Because I lived 2 years with a girlfriend that only speak english. But write correctly, it is a other story. So sorry I will write all the “my story stuff” in French. Because I want go sleep soon and don't pass the night to write
But for do small english resume I create a mod of a mod. I call my mod KMod++ because I rewrite all my new stuff in C++ in Oriented Object style and it is not the official Keneda stuff.
Sorry if you don't read french. Skip this long part and go watch the video to the end.
Je suis une forme de vie qui aime les jeux vidéo et la programmation. Je fais de l’émulation depuis asse longtemps. Avant même que j’ai eu internet ^^ Je participais sur les communautés et les BBS au Canada. Bon a l’époque j’avais 13 ans donc la programmation pour moi c’étais du chinois
Avec le temps, je me suis intéressé au monde de la programmation et plus exactement du ROMHacking pour les jeux vidéo. J’ai d’ailleurs divers traduction sur divers plateformes à mon actif. Et pour faire un bon romhacking, bien souvent on droit récrire de bonne partie de code ou voir refaire le rendu de la font, écrire des algo de compression pour réussir à rentré dans la rom etc. Parfois on grossi les rom et le classique sur MegaDrive/Genesis lorsqu’on agrandit la taille d’une ROM au delà de 2meg et bien on ce doit de faire une gestion intelligente de la SRAM ^^
Il y a 3 semaines un ami est venu me demander de l’aide sur un hack. J’ai regardé se qu’il me demandait et je me suis dit : « Merde… J’ai plus d’outils, mon HD à exploser j’ai tous perdu » J’ai réussi à récupéré quelque outils que j’avais fais mais sans mes sources bien sûr mais bon…
Un ami ma présenter Regen, j’ai fais tiens il a reprit le débuggeur d’instruction et le system de breakpoint de l’émulateur Russe : « Gens VKN Trace » que je n’arrive pas à dire son nom en russe enfin celui à cette adresse : http://shedevr.org.ru/cgi-bin/utilz.cgi?n=19. Quand aux outils de VDP, ils étaient une fusion du travaille de Keneda dans une fenêtre ^^ Globalement un choix judicieux Mais bon dans le cas Regen, n’était pas à mon gout et son gros point négatif ! Il n’est pas Open Source -_- Donc, je ne pouvais pas le mettre à mon goût. Même si il est plus « accurate ».
Mon choix c’est tourné sur KMod car aucune grosse modification n’a été à Starscream. Parfais pour mettre en exécution mon idée du moment. Pendant que ma copine me regardais crée mon émulateur et me posait des questions sur pourquoi la console marche et ainsi et blablabla… Elle est venu à me motivé. Et après avoir fini le hack de mon copain. Je me suis tourné à modifier l’émulateur pour lui expliqué comment la machine fonctionne. Elle aimait bien me regarder programmé et s’endormir contre moi pendant que je code. Donc ça ma motivé à bloque et tous les soirs en arrivant du boulot j’ai codé sur Gens KMod.
Donc en gros se qu’elle ma fait faire durant c’est 3 dernière semaine…
- Un débuggeur de 68k qui se base sur la création dynamique du mapping de la rom. Pour identifier se qui est du data et du code. Il détecte les fonctions et les labels durant l’exécution et crée le code source de la ROM.
- Le debugger à la possibilité d’arrêté l’exécution et de faire du Step-In, Step-Out, Step-Over. En gros si vous utilisé souvent des débuggeur pour debugger votre code C/ C++ vous aller savoir de quoi je parle.
- Un system de log des dernières instructions exécuté par le CPU environ 50 000 step. Donc vous pouvez en tout temps faire des step-back (Le step-back n’est pas encore totalement fini d’être implémenté. J’ai encore du support à faire pour la VDP) Surtout utile lorsqu’un breakpoint a été déclenché et vous voulez comprendre pourquoi vous êtes là.
- La possibilité de modifier la mapping de la rom et mettre des commentaires au niveau du code source. Dalleur lors de la création du mapping par défaut le header de la rom est commenté. Vous pouvez identifier le type de data d’ailleurs.
- Détection de changement entre les step d’instruction pour tous les types de VRAM, VSRAM, VCRAM, Z80-RAM et M68k RAM. En gros ça affiche en rouge les trucs qui on été modifier depuis le dernier step. Utile entre les breakpoint pour voir les changements.
- System de breakpoint avec un support illimité au niveau du nombre de breakpoint. Aucun ralentissement de l’émulation par exemple si tu as 1 000 breakpoint par zone de divers taille. L’algo de breakpoint faire la détection en O(1). Donc forcément y au un coups mémoire mais ridicule pour les machine de nos jours ^^
- System de callstack pour voir l’appelle courant des fonctions ! Et les Interrupt sont bien support toute supporté dans ce system ^^
- Et pas mal d’autre chose… comme le rendu réécrit en Direct3D 32bit pour plus que ça passe en 16bit inutilement et plein de goody comme ça Enlever tous les surface GDI pour faire du DirectX en hardware sur la carte graphique ^^
C’est ma copine qui ma encouragé à faire tous ceci c’est dernière semaine, sauf que pour l’option que je viens de finir de coder et que je veux vous montré vous devez ça à Stef. Car il m’a parlé y a quelque temps que ça serait cool si mon émulateur pourrais débuguer le code source C directement ^^
Mon passe-temps est le reverse engenering et ceci depuis que j’ai 13 ans et non les démos ou le développement. Mais bon mon métier professionnel est la programmation de jeux vidéo. Je dois faire ça depuis environ 6 ans et je dois dire que c’est crucial d’avoir des bons outils pour debugger. Car le « printf », les logs ne sont pas une solution viable. J’ai travaillé sur trop de console que les outils étaient à chier…
De plus Stef à fait beaucoup pour la scène, je me suis dis pourquoi ne pas regarder voir si je ne pourrais pas modifier mes outils pour supporter le débogage du code C. Alors c’est 3 dernier jours, j’ai échangé avec Stef et je lui ai demandé comment on fait pour simplement compile du code C sur Genesis. Il m’a référé à son SGDK. Et bon après la j’ai regardé comment bintuils générait les infos debug et j’en suis arrivé à ça aujourd’hui. Il me reste encore du travaille pour finir comme je veux le finir avant de faire un release public. Bien sûr, je vais faire des stages de beta test avec des volontaires et publier ensuite tous le code open source. Mais bon je viens de commencé et y a encore temps à faire…
Gardé à l’esprit que c’est du « ealy stage » Je viens de finir ça y a 30 minute. Donc je vais y donner encore de l’amour pour qu’on est de quoi de plus cool. Je vais crée un débuggeur de code source carrément sans l’assembleur pour rendre le tous plus facile à lire.
Donc chaque chose en son temps, j’espère que ça plaira à quelque personne autre que moi ^^
Sur ce je me la ferme…
So check this video : http://www.youtube.com/watch?v=V7RuJiSxGl0
And this video : http://www.youtube.com/watch?v=fk2PwJJMDZQ
And sorry for people that don’t read french I still love you
Now it is time to sleep... ^^
But for do small english resume I create a mod of a mod. I call my mod KMod++ because I rewrite all my new stuff in C++ in Oriented Object style and it is not the official Keneda stuff.
Sorry if you don't read french. Skip this long part and go watch the video to the end.
Je suis une forme de vie qui aime les jeux vidéo et la programmation. Je fais de l’émulation depuis asse longtemps. Avant même que j’ai eu internet ^^ Je participais sur les communautés et les BBS au Canada. Bon a l’époque j’avais 13 ans donc la programmation pour moi c’étais du chinois
Avec le temps, je me suis intéressé au monde de la programmation et plus exactement du ROMHacking pour les jeux vidéo. J’ai d’ailleurs divers traduction sur divers plateformes à mon actif. Et pour faire un bon romhacking, bien souvent on droit récrire de bonne partie de code ou voir refaire le rendu de la font, écrire des algo de compression pour réussir à rentré dans la rom etc. Parfois on grossi les rom et le classique sur MegaDrive/Genesis lorsqu’on agrandit la taille d’une ROM au delà de 2meg et bien on ce doit de faire une gestion intelligente de la SRAM ^^
Il y a 3 semaines un ami est venu me demander de l’aide sur un hack. J’ai regardé se qu’il me demandait et je me suis dit : « Merde… J’ai plus d’outils, mon HD à exploser j’ai tous perdu » J’ai réussi à récupéré quelque outils que j’avais fais mais sans mes sources bien sûr mais bon…
Un ami ma présenter Regen, j’ai fais tiens il a reprit le débuggeur d’instruction et le system de breakpoint de l’émulateur Russe : « Gens VKN Trace » que je n’arrive pas à dire son nom en russe enfin celui à cette adresse : http://shedevr.org.ru/cgi-bin/utilz.cgi?n=19. Quand aux outils de VDP, ils étaient une fusion du travaille de Keneda dans une fenêtre ^^ Globalement un choix judicieux Mais bon dans le cas Regen, n’était pas à mon gout et son gros point négatif ! Il n’est pas Open Source -_- Donc, je ne pouvais pas le mettre à mon goût. Même si il est plus « accurate ».
Mon choix c’est tourné sur KMod car aucune grosse modification n’a été à Starscream. Parfais pour mettre en exécution mon idée du moment. Pendant que ma copine me regardais crée mon émulateur et me posait des questions sur pourquoi la console marche et ainsi et blablabla… Elle est venu à me motivé. Et après avoir fini le hack de mon copain. Je me suis tourné à modifier l’émulateur pour lui expliqué comment la machine fonctionne. Elle aimait bien me regarder programmé et s’endormir contre moi pendant que je code. Donc ça ma motivé à bloque et tous les soirs en arrivant du boulot j’ai codé sur Gens KMod.
Donc en gros se qu’elle ma fait faire durant c’est 3 dernière semaine…
- Un débuggeur de 68k qui se base sur la création dynamique du mapping de la rom. Pour identifier se qui est du data et du code. Il détecte les fonctions et les labels durant l’exécution et crée le code source de la ROM.
- Le debugger à la possibilité d’arrêté l’exécution et de faire du Step-In, Step-Out, Step-Over. En gros si vous utilisé souvent des débuggeur pour debugger votre code C/ C++ vous aller savoir de quoi je parle.
- Un system de log des dernières instructions exécuté par le CPU environ 50 000 step. Donc vous pouvez en tout temps faire des step-back (Le step-back n’est pas encore totalement fini d’être implémenté. J’ai encore du support à faire pour la VDP) Surtout utile lorsqu’un breakpoint a été déclenché et vous voulez comprendre pourquoi vous êtes là.
- La possibilité de modifier la mapping de la rom et mettre des commentaires au niveau du code source. Dalleur lors de la création du mapping par défaut le header de la rom est commenté. Vous pouvez identifier le type de data d’ailleurs.
- Détection de changement entre les step d’instruction pour tous les types de VRAM, VSRAM, VCRAM, Z80-RAM et M68k RAM. En gros ça affiche en rouge les trucs qui on été modifier depuis le dernier step. Utile entre les breakpoint pour voir les changements.
- System de breakpoint avec un support illimité au niveau du nombre de breakpoint. Aucun ralentissement de l’émulation par exemple si tu as 1 000 breakpoint par zone de divers taille. L’algo de breakpoint faire la détection en O(1). Donc forcément y au un coups mémoire mais ridicule pour les machine de nos jours ^^
- System de callstack pour voir l’appelle courant des fonctions ! Et les Interrupt sont bien support toute supporté dans ce system ^^
- Et pas mal d’autre chose… comme le rendu réécrit en Direct3D 32bit pour plus que ça passe en 16bit inutilement et plein de goody comme ça Enlever tous les surface GDI pour faire du DirectX en hardware sur la carte graphique ^^
C’est ma copine qui ma encouragé à faire tous ceci c’est dernière semaine, sauf que pour l’option que je viens de finir de coder et que je veux vous montré vous devez ça à Stef. Car il m’a parlé y a quelque temps que ça serait cool si mon émulateur pourrais débuguer le code source C directement ^^
Mon passe-temps est le reverse engenering et ceci depuis que j’ai 13 ans et non les démos ou le développement. Mais bon mon métier professionnel est la programmation de jeux vidéo. Je dois faire ça depuis environ 6 ans et je dois dire que c’est crucial d’avoir des bons outils pour debugger. Car le « printf », les logs ne sont pas une solution viable. J’ai travaillé sur trop de console que les outils étaient à chier…
De plus Stef à fait beaucoup pour la scène, je me suis dis pourquoi ne pas regarder voir si je ne pourrais pas modifier mes outils pour supporter le débogage du code C. Alors c’est 3 dernier jours, j’ai échangé avec Stef et je lui ai demandé comment on fait pour simplement compile du code C sur Genesis. Il m’a référé à son SGDK. Et bon après la j’ai regardé comment bintuils générait les infos debug et j’en suis arrivé à ça aujourd’hui. Il me reste encore du travaille pour finir comme je veux le finir avant de faire un release public. Bien sûr, je vais faire des stages de beta test avec des volontaires et publier ensuite tous le code open source. Mais bon je viens de commencé et y a encore temps à faire…
Gardé à l’esprit que c’est du « ealy stage » Je viens de finir ça y a 30 minute. Donc je vais y donner encore de l’amour pour qu’on est de quoi de plus cool. Je vais crée un débuggeur de code source carrément sans l’assembleur pour rendre le tous plus facile à lire.
Donc chaque chose en son temps, j’espère que ça plaira à quelque personne autre que moi ^^
Sur ce je me la ferme…
So check this video : http://www.youtube.com/watch?v=V7RuJiSxGl0
And this video : http://www.youtube.com/watch?v=fk2PwJJMDZQ
And sorry for people that don’t read french I still love you
Now it is time to sleep... ^^