GB68K - Page 1

Je suis nouveaux sur ce forum donc je vais me présenter :
Je m'appelle Fred j'ai 19 ans et je suis en Terminale S. J'ai une Ti89 Titanium. Avant je possédez une Ti83+ et encore avant une Ti82 !
J'ai appris à programmer en ASM Z80 !

Bref je voulais poster un sujet pour savoir si vous connaissez GB68K l'émulateur Game Boy qui vien de sortir ?
Moi je l'ai telechargé et il marche avec quasiment tous les jeux mais il est ultra lent !
Le seul jeu jouable sur cet émulateur est Final Fantasy Legend !
Je voulais savoir si quelqu'un à réussi à faire tourner bien un autre jeu ?

Peut-être devrais-tu regarder les forums où on discute de ce jeu, principalement
http://p080.ezboard.com/ftichessteamhqfrm10
?

-

Mais j'ai testé tous les jeux là et beacoup d'autres et pas un fonctionne à vitesse raisonnable à part FFL !

-

Ce n'est pas la question !

J'ai juste demandé si quelqu'un arrivait à faire tourner d'autres jeux !

insolent.

Essaie simplement avec les jeux les plus "simples" que tu puisses trouver, par simple je veux dire avec peu de graphismes, peu d'objets mouvants à l'écran, etc (FF est un bon exemple). Comme l'ont déjà dit beaucoup, c'est déjà un exploit d'en arriver là, et il n'y aura jamais d'émulateur "jouable" de gameboy pour Ti (à moins qu'une Ti HW4 sorte avec un proc plus puissant, mais j'en doute ^^)

-

Euh la seule façon d'avoir un ému GameBoy assez puissant est de transformer directement la ROM sur PC puis l'envoyer sur TI. Et non demander au processeur de traduire en temps réel les instructions Z80.

Comme Kevin a dit, c'est exactement ce qu'il fait.

Hmm donc c'est plus un émulateur dans ce cas là ?

geogeo :
Euh la seule façon d'avoir un ému GameBoy assez puissant est de transformer directement la ROM sur PC puis l'envoyer sur TI. Et non demander au processeur de traduire en temps réel les instructions Z80.

Non ça ne peut etre fait de maniere efficace pour plusieurs raisons (et je sais de quoi je parle)

Emuler un processeur de 1Mhz sur une machine de 10 ou 12 Mhz est tout a fait faisable, mais en codant de maniere tres propre (et en optimisant en ASM)

et non c'est pas un exploit, meme si le hard video d'une gameboy est plutot complexe

Heu Kevin a justement dit l'inverse
les instructions sont interpretées là comme dans un vrai emulateur (il a utilisé un bout de tezxas meme je crois)

Moi je me demandais si en convertissant en instruction 68k si ca prendrait beaucoup plus de place ?

Bah oui mais ça serait bien plus rapide.

Non ça ne peut etre fait de maniere efficace pour plusieurs raisons (et je sais de quoi je parle)

Pourquoi dont? Ok y a le côté hardware a émuler après.
Mais je me rappel déjà voir vu des émulateur de GameBoy sur des machines à 10 MHz. La GBA émule comment la GameGear, NES, GameBoy; je ne sais pas si elle utilise le Z80 interne et j'en doute?

lionelA > KK il connait rien aux jeux et aux optimisations de vitesse donc faut pas le prendre en reference qd ca touche a ce domaine

KK a juste cité l'auteur (et d'ailleurs j'ai mal compris; c'est lionelA qui a raison )

geogeo :
Bah oui mais ça serait bien plus rapide.

Non ça ne peut etre fait de maniere efficace pour plusieurs raisons (et je sais de quoi je parle)

Pourquoi dont? Ok y a le côté hardware a émuler après.
Mais je me rappel déjà voir vu des émulateur de GameBoy sur des machines à 10 MHz. La GBA émule comment la GameGear, NES, GameBoy; je ne sais pas si elle utilise le Z80 interne et j'en doute?

Je sais pas, mais la gba a un gu et un hardware orienté graphique en général, ce qui n'est pas exactement le cas d'une TI.

lionelA :
Heu Kevin a justement dit l'inverse
les instructions sont interpretées là comme dans un vrai emulateur (il a utilisé un bout de tezxas meme je crois)

Moi je me demandais si en convertissant en instruction 68k si ca prendrait beaucoup plus de place ?

Kevin est loin d'etre expert Es-emulateur, surtout sur TI

Geogeo: Pourquoi ?
pasque "convertir" le code Z80 en code 68000 n'est pas suffisant, et en plus on ne peut pas convertir betement le code, sans tout casser (les graphiques sur GB sont placé n'importe ou dans le code, donc faudrait pouvoir parser intelligement la rom, ce qui est tres difficile)

> KK il connait rien aux jeux
Telle que tu l'énonces, c'est faux. Il faudrait nuancer...
> et aux optimisations de vitesse
C'est faux aussi: il connaît les techniques, mais il est complètement contre. Pour lui, seule l'optimisation (extrémiste) taille compte. Il n'est d'ailleurs pas très bon à ce petit jeu-là, voir les 20 octets sur environ 1000 que j'ai gagnés sur le pstarter de TIGCC (qui est, contrairement à ce qu'il dit, presque toujours à foutre à la poubelle de toute façon, vu qu'un lanceur générique gagne de la place dès qu'il y a plus d'un seul lanceur spécifique, même en utilisant la routine rapide de décompression PPG)...

bon j'ai vraiment du mal m'exprimer,
Je disais juste que lorsque geogeo disait que l'auteur avait dit qu'il faisait ca, Kevin avait dit le contraire, ce que JfG avait interpreté en inverse donc voilà ce post on ne peut plus clair .

C'est clair que c'est dommage qu'on ne puisse pas convertir brutalement le code z80 en 68k... En créant un environnement pour reproduire le HW de la GB, les jeux tourneraient correctement.
Enfin, je pense qu'on pourra peut-être obtenir un ému suffisant, il faut qu'on s'efforce de l'optimiser au maximum.

Sasume
: C'est clair que c'est dommage qu'on ne puisse pas convertir brutalement le code z80 en 68k... En créant un environnement pour reproduire le HW de la GB, les jeux tourneraient correctement.

C'est malheureusement impossible pour bon nombre d'émulateurs. Les meilleurs méthodes d'émulation actuellement sont les JIT qui font de la recompilation, mais a la volée, pas "brutalement". Pour pouvoir le faire "brutalement" il faudrait etre certain que les données ne sont pas lié au code (ce qu'on peut faire pour du java et du MSIL, mais pas pour de l'émulation de machine malheureusement)

Enfin, je pense qu'on pourra peut-être obtenir un ému suffisant, il faut qu'on s'efforce de l'optimiser au maximum.

Pas forcement, un peu d'optimisation oui, mais pas forcement au maximum, la facon dont l'ému est fait joue ennormement

Oui, déjà il n'utilise pas les registres du 68k pour contenir les registres du processeur émulé. Je pense que ça serait facilement possible et ça accélèrerait déjà pas mal...
Sinon, on peut essayer de trouver mieux pour le décodage d'instructions, mais ce n'est pas évident...


Pour la compilation JIT, il y a certains cas où je vois difficilement comment ça peut être "sûr".
Genre pour le self-modifying code, ou si on trafique n'importe quoi avec la pile.

Godzil
: C'est malheureusement impossible pour bon nombre d'émulateurs. Les meilleurs méthodes d'émulation actuellement sont les JIT qui font de la recompilation, mais a la volée, pas "brutalement". Pour pouvoir le faire "brutalement" il faudrait etre certain que les données ne sont pas lié au code (ce qu'on peut faire pour du java et du MSIL, mais pas pour de l'émulation de machine malheureusement)

On ne pourrait pas faire du JIT et laisser les lectures en mémoire toujours pointer dans le code original pour tout ce qui est donnée ?

Sasume :
Genre pour le self-modifying code, ou si on trafique n'importe quoi avec la pile.

C'est vraiment fait ce genre de trucs sur GB ?

>On ne pourrait pas faire du JIT et laisser les lectures en mémoire toujours pointer dans le code original pour tout ce qui est donnée ?

Memoire pas assez grande.

ExtendeD :
On ne pourrait pas faire du JIT et laisser les lectures en mémoire toujours pointer dans le code original pour tout ce qui est donnée ?

A condition :
- (dans le cas de self-modifying code) de pouvoir voir quand les écritures posent pb
- de pouvoir convertir dynamiquement les offsets dans le code z80 en offset 68k (jump tables ou truc plus vicieux)
etc...
Ca impose des grosses pénalités, sans compter que pour tout ce qui est I/O, il faut analyser chaque écriture/lecture en mémoire, c'est tres couteux...

J'ai déja du le dire dans des vieux topics, mais je pense qu'il faudrait d'abord faire une analyse statique semi-automatique du code sur PC pour déja éliminer les cas simples (tel registre pointe sur telle variable en RAM, tel registre contient un offset entre deux labels du code, tel endroit n'est jamais exécuté donc c'est des données et pas la peine de le convertir en code 68k, etc...), et apres raffiner éventuellement pour etre sur que les boucles exécutées souvent ne contiennent pas de vérifications inutiles...

PpHd :
>On ne pourrait pas faire du JIT et laisser les lectures en mémoire toujours pointer dans le code original pour tout ce qui est donnée ?

Memoire pas assez grande.

pas sur pedrom (puisqu'on peut exécuter a partir de la flash)

Oue mais sans relogement et encore limite a 64K de code.