Emu gba sur gp32 - Page 1

Et si on faisait un topic pour donner des idees pour la creation / portage d'un emu gba?

Le refaire de 0?
Porter un emu deja existants?
Utiliser le MMU pour modifier les addr des i/o?

Creer un groupe de travail pour se pencher sur le code.

Enfin bref tout pour faire l'emu gba le plus rapide et fidele possible sur la portable la plus
puissante du monde.

(Pour les septiques, oui c realisable un emu gba)

ca veut dire, que va y avoir une GBA, avec un ecran énorme, de bonne qualité, avec le son stéréo, des gachettes super, un bon stick, et un dumper offert avec ???

GP32 RULEZZZZ !!!!

>>>>Utiliser le MMU pour modifier les addr des i/o?

Sans hesiter. mais il faudra aussi gerer le decoupage des fichiers ROM GBA (Je sais pas, ca pourrait depasser 8 Mo et alors...). Puis la mapping memoire de la GBA est assez complexe. Y'a aussi le probleme des interruptions a activer au bon moment (Hint, VInt entre autre).

Inconvenient : Si le jeu utilise le MMU, ben c'est kaput. On pourra plus. M'enfin ca reste a voir.

c koi le mmu ?

Memory Management Unit. Truc qui permet de decoder des adresses logiques en adresses reelles. elle declenche une exeption si on accede a une adresse qui n'existe pas. Et l'expetion peut soit faire une permuttation de page, utiliser la swap ou terminer le prog si c'est pas bon. Dans notre cas, on accede aux i/o, et on fera le remapping de la memoire.

et tout ca en 3 lettres, waaaaa, heuresement que j'ai rien compris !

pphd > tu as pas une doc un peu plus detaillé (parce que c un peu brute ton msg )

Prend une doc sur un microprocesseur. C'est pourtant simple.
Y'a le ALU, le FPU, le MMU, le CPU, le GPU, ...
Bref, c'est le truc qui decode une adresse logique en adresse reelle. C'est plus clair ?

Tu decoupes en paquet de 16 K (ce qui fait 512 pages pour une ROM de 8Mo). Avec 6Mo alloue a la ROM, on aurait acces a 384 pages directement !
Puis la recherche de la page la moins frequente peut se faire en lb(384) = 9 iterations.
Je pense que ca a de grandes chances de marcher quand meme

Où on les auras les jeux?

Laisse tomber, de toute facon, ce que j'avais ecrit, c'etait des conneries.

lol....PpHd, mais non !!

en tous cas, ZardozJones est confient et tres motivé pour le faire. De plus c un developpeur professionel, donc wait & see.
Pour ma part je suis optimiste, mais je pense qu'il y aura des tps de chargement pour les cartouches de plus de 4 megas car les plus grosses ne tiendrons pas en ram

Heu....
Y'a pas de MMU sur la gp32, voila ma connerie.

hein? sur le data sheet du microcontroleur de la gp32 ya dans l'arn920T un mmu!

Je ne comprend plus bien la!

Heu, y'a un MC (Meory Controlleur) qui permet de controller differents types de memoire.
Pas de MMU (Memory Mangament Unit) avec systeme de memoire virtuelle.
En tout cas, je l'ai pas lu sur la doc du micro-controlleur.

ha ok, decidement tu es très fort PpHd

Je lis les docs

c surtout tu comprends les docs...

Tu sais : question d'habitude

modeste PpHd

Alors voila : d'apres certains, l'emu gba sur gp ne peut tourner, ca il faut d'abord transferer la rom par la ram, qui est limitée a 4 MO.

Mais comment font les jeux officiels ? Meme question pour les fichiers du genre divx ou Mp3 !

Voila, j'y connais pas grand-chose mais si vous pouviez un peu m'epxpliquer ca je ne vois pas vraiment comment c'est possible pour certains types de fichiers et pas pour d'autres !

Je ne saurais t'expliquer en detail.

Je peux juste te dire que l'emu gba est en cours de developpement, et que les premiers screenshots sont attendus pour la semaine prochaine.

Disons que pour un mp3 les infos sont les unes a la suite des autres, pareil pour le divx, alors que les roms comme se sont des images de jeux, il faut pouvoir y acceder tres rapidement pendant l'execution de l'emulateur.
Donc effectivement, on va etre limite au debut aux cartouches de 4mo de la gba (50% des jeux)
mais on trouvera des astuces (genre tps de chargements)

Je ne comprends pas en quoi les temps de chargement changeront qqch

admettont que tu ai 8mo de ram libre, et que la rom fait 16mo,
il va donc te manquer 8mo de donnees de jeu. Or les donnees de jeux ne sont pas les unes a la suite des autres,
donc dans les 50% que tu a reussit a stocker en memoire il n'y a pas forcement les 50% du jeu,
admettont qu'il y ai les menus, les sons et un niveau.
Toi tu as un mot de passe pour aller au niveau 2, mais manque de chance celui-la n'est pas en memoire, il va donc
falloir liberer de la memoire (imaginon qu'on degage les menus) puis ensuite charger le niveau 2.
Pour faire cette operation il faut du temps, d'ou un temps de chargement car il faut aller chercher sur la smc la bonne partie de la rom,
extraire le niveau 2 et tout ce qui lui est attache (monstres, musiques) qui n'est pas encore en ram, puis
une fois qu'on connait la taille de ce qu'il faut mettre enram, liberer une partie de celle-ci (en enlevant les menu par exemle)
et tout et tout. C un peu confu comme explication mais bon, j'arrive pas a exprimer ca + clairement.

en bref, on fait une tambouille pour que les bons elements soitent en ram au bon moment car on peut pas tous les mettres.

Pour la gba, 50% des roms font 4mo, ce qui tient largement dans les 8mo de la gp32.

Ouf, j'an enfin compris Merci de l'explication !

Mais bon je pense que la plupart des joueurs gp32 seraient d'accord pour patinter quelques insants, meme si a mon avis, "decouper" le jeu doit ere assez difficile ...

Non découper le jeu n'est pas si difficile. Mais ca obblige a mettre une indirection supplemenmtaire pour les access memoire et donc baisse de performance

mais cette baisse de pref peut etre compensee par la cadence du proc non?

vous prenez ps le choux !!
on verra les resultat !!

>yenaphe: Je ne sais pas. Ca depend s'il est limite ou pas.