Émulateur de GameBoy pour TI - Page 9

Je trouve que c unsacré défi de faire tourner un émulateur sur un caltos tout de même. Faut voir la config qu'il demande sur PC (même pour le gb) pour tourner! Et la avec 12MHz

C pas le premier emulateur qui existe sur nos TI !!

je sais plus qui avait deja fait un emulateur de ZX80 (si je me rapelle bien) et sa marchait plutot bien

Sinon y'a un émulateur de CASIOs sur TIs qui tourne très bien

C'est lent, mais c'est normal puisqu'il émule une Casio !

c'est vrai?
je peux le dl où?

arf
je rigolais pas, ça doit être poilant!
mais faut faire 1pixel =>4x4pixels
sinon on y verra rien

si, on voit tres bien ac celui de Thibaut

En ce qui concerne le HLE, j'ai fait un algorithme de force brute, analizé qqs roms et je n'ai trouvé presque aucune ressemblance, même entre des jeux de nintendo. Donc, pas d'API. Je suis en train d'implementer le HLE, mais ça ne sera pas du tout génerique (il va faloir ajouter des fonctions pour chaque jeu). Je vous informerait sur mes progrès.

Ce serait intéressant de voir quelqu'un adapter le super GB sur la TI. Mais il va faloir pas mal s'y conaitre à l'électronique.

c'est bien ce que je pensais!
pour faire des jeux comme ça sur un si petit HW il faut que ça soit optimisé dc pas d'api

ya pas de bios sur les GB, donc pas d'api ! (enfin, il pourrait malgres tt y avoir une librairie statique que fourni nintendo, mais sa m'etonnerait.. Vu la diversité du HW des cartouche qu'on peut trouvé (notemment avec la NES) c impressionant...

Je ne comprend pas pourquoi vous ne faites pas plutot un convertisseur de rom gameboy => ti, il n'y aurait pas l'emulation, vu que ca serait direct du code natif, donc gain de vitesse! un convertisseur ne doit pas etre tres dur a programmer si on a deja un emu qui tourne meme lentement, je suis sur qu'on pourrait arriver a des jeux potables!

Se probleme dans le monde de l'émulation a déja été posé, lit les doc sur "comment creer un emulateur" tu comprendra mieux.. Ya deux chose qui s'opose a sa :

1 - On peut pas vraiment faire la différence entre Code et Data (c assé génant de changer les sprite qund meme nan ?)

2 - Si tu a affaire a du code automodifiant c pareil t ...

Voila pourquoi un "emulateur" comme sa n'existe pas...

La deuxieme raison est assez explicite

---------

à condition de désassembler les jeux gb (si un tel dasm existe), on peut très bien imaginer de convertir les srcs : Source Guru le fait déjà.
(http://www.ticalc.org/archives/news/articles/2/26/26840.html)

Attention ! Source guru traduit les prog TI-85 dans un format particulier (le shell old school) vers un format kernel pour TI !

Si je m'abuse, le code doit etre bien séparé des data dans se type de prog (ou alors source-guru fonctionne uniquement avec les source nan ?)

Le type d'"emulateur" dont on parlait plus haut, ne repart pas des sources, mais directement de la source compile !

Et pis désasembler un jeu de GB c pas difficile !
Tu peut trouver des tonnes de désasembleur Z80 sur le net !

godzil a écrit :
Attention ! Source guru traduit les prog TI-85 dans un format particulier (le shell old school) vers un format kernel pour TI !

oué sans doute

Si je m'abuse, le code doit etre bien séparé des data dans se type de prog

en kernel ??
ben non pas spécialement

(ou alors source-guru fonctionne uniquement avec les source nan ?)

oué, oué. ça converti les scr z80 en 68K

Le type d'"emulateur" dont on parlait plus haut, ne repart pas des sources, mais directement de la source compile !

c pour ça que je parle de dasm ;p

Et pis désasembler un jeu de GB c pas difficile !

ben alors ou es le pb ?

Tu peut trouver des tonnes de désasembleur Z80 sur le net !

parrrfait !


qui s'y colle ?

Ben non pas parfait !!


Quand tu utilise source guru, tu prende les source originales, donc le code et le data sont clairement visible !!

Mais si tu pars d'un prog asemblé, et que tu le desasemble, comment tu fait la difference entre le code et les data ???

On retombe tjours sur le 1er probleme que g cité...
Donc c'est pas possible...

Enfin si, mais tu passe 3 mois a faire la décomposition data/code a la main...

Mais la ta plustot interet a etre un Guru Asm Z80 !!!

Surtout vu la taille importante des roms...

En supposant que les roms ont une parie clairement séparée (code/datas) ce qui doit etre un peu pres le cas.. ils vont pas s'ammuser a les foutre en plein milieu du code non?
voila ce qui peu etre faire:
-Si les graphs sont compressés, il faut alors reperé les routines graphiques élémentaire (affichage de sprite...) et récupérées les adresses chargées.. apres il faudrait prendre l'addresse la plus faire pour que l'on ai le debut des datas.
- Si ce n'est pas compressé et que l'on connais le format des prite tiles, on peut alors faire un viualisateur de rom au format graphique (ya ca sur HP.. et on arrive a retrouver les images des jeux et de les modifiers..) et alors on a le debut des datas..

Enfin j'y connais pas grand chose aux gb..

Ouai mais bon, meme si on peut arriver a faire sa a la main (g pas dit que ct impossible a le faire a la main) sa n'est tjrs pas automatique (la été l'idée originale)

Ensuite, une fois que ta séparé le code des data (d'ailleur je m'attendrait bien a se qu'il y est des fois des data entremelé dans le code, cf ceux qui font la traduction des jeux (du ROMHack comme qu'il l'appele) les dialogues sont rarement d'un bloc ensemble...) convertir "betement" le code Z80 en 68k tu va avoir des suprise ! le HW de la 89 est quand meme tres != de celui de la GB et faudra encore comprendre le programme pour savoir se qu'il fait et changer les partie qui font (par ex) lire les touches, afficher a l'ecran par un equivalent (en utilisant une lib comme Xlib ou graphX par ex) modifier aussi pour séparer completement source et data pour les mettre dans des fichier (64K limit powaa une rom de GB fait facilement 100k..)

A la main, tt est possible (heureusement!) mais perso, faire un prog qui convertise tt seul une ROM de GB en programme pour TI, c ptet realisable, mais la taille de boulot a faire, est alors considerable, largement plus que faire un emulateur "potable" sur la TI... D'ailleur, quoiqu'il en soit, sa résoud tjrs pas le pbm de code automodifiant...

Et ça sera surtout plus lent que de reprogrammer soi-même le jeu en ASM68k ou en C

D'abord pour ceux qui veulent se renseigner sur le GB, j'ai publié http://www.boogersoft.com/projects/tigb/gbspec.txt (c'est presque le 99% des informations dont je me suis servi pour écrire l'émulateur, mais c'est pas un document énorme, donc lissez-le)

Bon, je pense que ce que vous voulez faire est, pour pas dire imposible, très très très dur à faire. En voilà quelques raisons qui me vienent à l'esprit:
- C'est pas gateau de séparer le code du data
- Le self modifying code va poser des gros problèmes, et dans le GB les jeux s'en servent pour faire du DMA (puisque lorsque l'on fait du DMA seule la HIGH RAM est accèssible, donc ils copient la fonciton qui fait le DMA dans la HIGH RAM puis ils sautent)
- Les jeux n'écrivent jamais sur l'écran (car ceci n'est pas *directement* posible). L'écran du GB travaille en TILES et TILE TABLEs, et celles-ci sont dans des endroits de la RAM totalement différents (lissez la section VIDEO de gbspec.txt).
- Le z80 utilise le régristre A (Acummulateur) presque pour tout faire vu que c'est le seul régristre que l'on peut utiliser pour lire/écrire dans la RAM et pour faire certaines opérations mathematiques, et ce serait difficile de détecter ce genre de trucs et les optimiser.
- Pour emmerder encore les choses: le 68K et le Z80 travaillent différament dans la mémoire (little endian vs big endian), et l'instruction move du 68K détruit les flags (alors que l'instruction ld du Z80 non).

Cela dit, on peut conclure que, même si on y arrivait, les jeux prendraient une place énorme en RAM, et on devrait continuer à faire tous les checks et sauvegarde de flags que fait déjà mon emu. Toutefois, je laisse le débat ouvert au cas où quelqu'un veut me contrdire. Mais lissez gbspec.txt, comme ça on pourra parler des détails.

Je vais faire quelques test, mais je pense que le HLE devrait ammener des gains de vitesse considérables avec peu de travail de traduction. On verra bien ce que ça donne.

J'ai oublié, mais 'faudrait aussi chequer (on dit comment chequer en français?) dynamiquement sur quel endroit de la RAM écrit le jeu pour rester compatible avec l'I/O qui est memory mapped en sa totalité. Bref, on retombe sur l'émul, mais ça prend plus de place.

deja checker=verifier
et on dit liSez pas liSSez

tu utilse une lib graphique pour l'affichage?

janjan2 a écrit :
deja checker=verifier
et on dit liSez pas liSSez
tu utilse une lib graphique pour l'affichage?

Merci des corrections. N'hésitez pas à me corriger si j'écris des ânneries de ce genre .

J'utilise ma propre lib graphique qui s'occupe de lire la RAM du GB et transformer cela au format du LCD de la TI (Le GB n'écrit pas directement sur le LCD, mais il travaille en layers - background, window et object). Je ne pense pas qu'il y ait une librairie qui me soit utile vu que j'ai pas mal de buffers intemédiaires que j'utilise pour optimiser (ie: éviter de relire la RAM et reconvertir les données à chaque frame).

Cette lib est dans lcd.h/lcd.asm. Je vous conseille de lire la section VIDEO de gbspec.txt avant.

Ditez, on prévient comment le "bouncing" du clavier (lorsque l'on appuie une touche une seule fois mais ça crée des oscillations et l'on reçoit n'importe quoi?)

arf, tu peux pas à ma connaissance

pour regler le "boucing" du clavier, je pense qu'il faut prendre en compte une touche que si elle a ete appuyee pendant un certain temps. Si le temps est superieur au temps des oscillations, les oscillations ne seront pas detectes.