Recherche un initié en programmation / émulation

[MockyLock]

Mwap à tous!

Alors wala, je suis en train de rédiger des petits guides pour apprendre à se servir des quelques copieurs que je possède.

Seulement il y a des choses qui m'échappent. Je cherche donc quelqu'un qui a des notions en programmation pour émulation. Je m'explique, voici ce que je voudrais apprendre:

 

CHECKSUM: à quoi sert de calculer le checksum d'une rom ?

 

HEADER: qu'est ce que le header d'une rom et quoi cela sert-il de le copier/coller dans une autre par exemple ?

 

SWAP BYTE: qu'est ce que le swap byte ? Je le traduirais par "inversion de byte", donc à quoi cela peut-il serbir de swaper une rom ?

 

Bien sûr, il va de soit que le généreux forumien qui m'aiderait sera cité dans ledit guide =)

Merci !

[mimix]

je suis pas pro, mais il me semble que calculer le checksum c'est vérifier qu'elle n'est pas corrompue.

 

header c'est l'entête il me semble. ça détermine la région, la version etc ...

 

swap byte ça me reviens pas. c'est effectivement une fonction d'inversion mais je me rappel plus trop ... de loin je dirais que ça sert à inverser les bytes entre la fin et le début uns à uns pour créer une rom miroir ... dans le but de la balancer dans un programmateur d'epproms.

mais je suis pas certain. il me semble que c'est nécessaire de faire ça pour programmer les eeproms snes ou megadrive ...

 

tout comme pour les roms nes où il existe une opération pour diviser la rom en deux pour la balancer dans les deux eeproms qui composent la cartouche... mais alors le nom de l'opération ... je m'en rappel plus ! le but c'est qu'au final certaines données, celles du jeu et celle des graphiques, soient séparées et traitées indépendament par la nes avec le ppu dédié à chaque tâche.

 

 

mais tout ça je le dis sans être 100% certain, c'est des souvenirs de fond de boite cranienne qui demandent à être vérifiés ! mais si ça peut t'aiguiller dans ta recherche

 

sinon très sympa cette idée de guide !

Modifié le 17 novembre 2008 par mimix

[MockyLock]

Merci mimix pour ton intervention =)

Pour ce qui est du checksum (check summary il me semble): moi aussi je pense que c'est un genre de CRC, mais on peut tout à fait faire fonctionner des roms avec un "bad checksum". Alors du coup, je ne comprends pas trop...

Le header: donc, copier le header d'une rom dans une autre, ça permettrait de la faire passer pour une rom d'une autre région par exemple ?

Le swap: à quoi cela pourrait-il servir dans un copieur alors (mon CD64 a cette option)?

 

Quand à l'opération de division des roms, c'est pas la split ? On s'en sert aussi pour les copieurs 16bit, pour diviser les roms en autant de disquettes nécessaires.

[mimix]

tu arrives à les faire tourner sur émulateur oui ! mais les balancer dans une eeproms qui n'a pas plus de place que le nombre de bytes pour lequel était prévus le jeu à l'origine, là je crois pas que ça marche .

 

pour le header oui ça peut être ça !

 

le swap euuuuh, alors bonne question ! merci de l'avoir posée !

 

pour l'opération de la nes c'était assez particulier , c'était un simple split où on coupe un fichier, c'était sélectif !

[Infogames]

Checksum:

Somme de contrôle - Wikipédia

 

Header:

Header (informatique) - Wikipédia

 

Swap byte: (mais c'est plus visée dans "Swap" le contenu de ce document)

Mémoire virtuelle - Wikipédia

 

 

Voilà

[Dwight]

Le check sum comme l'a expliqué mimix sert à contrôler l'intégrité de ton fichier. C'est une somme obtenu à partir d'un algorithme donné qui a statistiquement peu de chance de donner le même résultat si ton fichier a été modifié. Pour vulgariser c'est une sorte de "preuve par 9".

CRC32 est un de ces algorithmes, mais il en existe beaucoup d'autres : MD5, SHA1, SHA256, ADLER32... pour ne citer que les plus connus.

 

Le header, rien à rajouter.

 

Swap byte : je n'en suis pas trop sûr, par contre le lien qu'à posté Infogames est hors sujet. Cet article wikipedia s'applique dans le cadre de la gestion mémoire effectuée par un OS, rien à voir avec ce qui nous occupe.

Je ne suis pas sûr du tout mais je pense que cela à peut être un rapport entre une conversion big/little endian ?

[mimix]

bon ça va chui pas trop con on est deux à penser pareil

[MockyLock]

Mwap!

Merci, merci beaucoup pour votre aide.

Petits récapitulatifs:

 

CHECKSUM: Donc on est d'accord, c'est un calcul de vérification d'intégrité de fichier. A quoi cela peut me servir dans un copieur (dans mon CD64 en l'occurence) ? J'ai déjà booté des roms avec un "Bad Checksum" (sur des émulateurs SNES par ex, pas sur le CD64). Surtout que le CD64 n'a pas d'option de correction de checksum.

 

HEADER: c'est un fichier d'entête contenant des inforamtions relatives à la rom qui suit. Copier/coller le header pourrait donc donner au copieur de fausses inforamtions sur la rom et permettre de booter les roms ainsi modifiées ?

 

SWAP BYTE: alors là je vous copie/colle un extrait de la FAQ de uCON (logiciel avec plein d'applications pour roms):

 

Nintendo 64

Interleaved Nintendo 64 dumps are produced by the Doctor V64 and the Doctor V64 Junior. Perhaps "byte-swapped" is a better term for Nintendo 64 dumps. For each two bytes the first and the second byte are swapped.

Can be interleaved with uCON64 using the option -v64.

Can be deinterleaved with uCON64 using the option -dint, but it is better to use the regular conversion option -z64.

 

donc le SWAP BYTE dans le CD64 pourrait servir à convertir des roms du format V64 en Z64 et inversement ?

 

N'hésitez pas à me donner vos avis.

Mes tutos sont en phase d'achèvement, je pense même en mettre en ligne aujourd'hui =)

[MockyLock]

Re

Euh, je vais peut-être paraître con mais je n'arrive pas à copier/coller mon document Word sans qu'il ne change de mise en page.

En fait, j'aimerais qu'il garde ma mise en forme (en particulier les puces et numérotations).

Comment qu'on fait siouplait ?

[mimix]

euuuh, copier coller sur le forum ?

pour ça faudrait qu'il gère les puces...

 

pour le swap byte j'ai bien l'impression que c'est ça.

pour le cheksum, il peu être faux et que le jeu marche bien ! suffit que ça soit juste un 1 ou un 0 placé pas comme il faut mais qui gène pas la structure globale du jeu et ça marche ! comme ça peu aussi buguer plus tard comme au départ, comme juste déformer une texture, comme ne rien faire si le bad checksum est issus d'un traitement de la rom par un logiciel (genre pour une traduction)

 

en tout cas un mauvais checksum autre part que pour un linker doit entrainer forcément un ratage si il sagit de balancer dans une eeprom de taille prévue au plus juste au départ !