Émulateur de GameBoy pour TI - Page 1

Bon voilà un preview du truc dans lequel je suis en train de travailler
http://www.boogersoft.com/tigb-preview.zip

C'est seulement les binaires, non pas que je ne veuille pas montrer les sources mais parce que c'est un preview qui n'est d'ailleurs pas stable, et j'aimerais y travailler un peu plus avant de le dévoiler

Bon, quand aux détails:
- Il marche assez vite dans virtual ti sans limite de speed (sur l'ordinato dans lequel je bosse ça fait dans les 250% OC)
- Il marche seulement sur ti-92+ pour l'instant (Fargo, AMS 2.05, HW2, autres configurations j'en sais rien )
- Vous aurez bessoin de toute votre RAM (ce que prennent les binaires + 65k pour la RAM du GameBoy), donc envoyez tout tout tout dans la ROM.
- Vous devriez pouvoir utiliser n'importe quel ROM de 32k (c.à.d. type 0=ROM ONLY), il suffit de remplacer le rom.gb inclus (tetris, au fait) par un autre et recompiler rom.asm
- Touches: curseur=déplacement, enter2=start, apps=select, f1=A, f5=B, mode=montrer le debugger
- Dans le debugger vous pouvez faire 'H' pour voir les commandes
- À n'utiliser que sur VTI parce que ça risque fort de planter votre calculette
- Le binaire à exécuter c'est cpu.9xz (et non pas rom.9xz ou machinlib.9xz)

Avant que j'oublie, ça m'aiderait si quelqu'un répondait à mon autre post "HW2 grayscale" car cet emu écrit dans deux paneaux mais je ne sais toujours pas comment faire du bon gray

À plus,

Euh... erreur c'etait pas Fargo c'est DoorsOS!

Encore trois trucs oubliés

- ESC=sortir de l'émulateur
- Il y a beaucoup de self-modifying code donc je vous conséille de récopier cpu.9xz et lcdlib.9xz à chaque fois que vous rédémarrez l'emu...
- Si l'emu refuse de démarrer c'est 99% que vous n'avez pas assez de RAM (65k au minimun, >80k en pratique). Essayez 2 ou 3 fois car non seulement il a bessoin de 65k mais aussi il faut qu'ils soient contiguous.

je peux pas voir ca la, je regarrderais ce soir moi

Dommage que ce soit si lent.
Et utilise les gray de tigcclib ou graphlib, ou est le problème ?

Dis, tu fais comment pour la reconnaissance des instructions ? je ne connais pas trop ton niveau (tu dois être pas mal fort d'après ce que tu as fait ) mais il doit y avoir moyen d'accélérer l'émulateur en optimisant de ce côté là

bravo!

Thibaut a écrit :



Dis, tu fais comment pour la reconnaissance des instructions ? je ne connais pas trop ton niveau (tu dois être pas mal fort d'après ce que tu as fait ) mais il doit y avoir moyen d'accélérer l'émulateur en optimisant de ce côté là

Il faut lire le rom instruction à instruction et exécuter des instruction équivalentes de 68000 et émuler les flags. Mais cette partie est la plus couillon quoi, le plus dur c'est toute l'istoire des interruptions et du display...

Bien sûr, il y a encore pas mal d'optimisations auxquelles je peux penser, dont du HLE (High level emulation), des jumptables encore plus grandes (de deux instructions au lieu d'une seule à chaque saut -> encore + de RAM nécéssaire!!!), ne pas rédessiner l'écran à chaque fois, etc... Ma devise c'est "first make it work, then make it work fast".
Toutefois, je suis moi même surpris de la vitesse (je ne m'y attendait pas à mieux qu'une 100aine de fois + lent ), donc je pense qu'avec la TI à disons 20MHz (c.à.d. pas trop overclockée) et en réglant le frameskip ça devrait aller.

Oui mais quand tu lis une instruction, pour déterminer de quelle instruction il s'agit et effectuer le traitement en conséquence, tu fais comment ?

Thibaut
a écrit : Oui mais quand tu lis une instruction, pour déterminer de quelle instruction il s'agit et effectuer le traitement en conséquence, tu fais comment ?

Ben la plupart des instructions du Z80 (le CPU du gameboy) font 1 byte, donc on se fait une jumptable de 256 entrées et voilà.

Le autres instructions commencent par $CB et font deux bytes en tout, donc voilà une autre jmptable de 256 entrées.

ok ben on fera difficilement mieux
Ca fais combien de temps que tu progs ? tu as l'air vachement calé
Tu pourrais me montrer la source de ton émulateur ?

Thibaut a écrit :
ok ben on fera difficilement mieux Ca fais combien de temps que tu progs ?

À peu pres 8 ans, mais sur 68000 2 mois

Tu pourrais me montrer la source de ton émulateur ?

Patience. Ça viendra. Ce sera du GPL, mais je ne veux pas sortir une version officielle avant d'avoir quelque chose de concis, ce que vous aurez du remarque n'est pas le cas.

Je pense que d'ici une semaine il y aura quelque chose...

ben Bravo, tu a l'air très bon en effet !

C'est du C ou de l'asm ?

Terrible Franchement c vraiment du bon boulot (j'ai regardé dans le debugger et ça a l'air pas mal programmé, surtout si t'as commencé y a 2 mois )


Sinon un truc tout con :

lsl.w #2,d0
move.l x(pc,d0.w),a0
jmp (a0)

= 36 cycles


add.w d0,d0
move.w x(pc,d0.w),d0
jmp 0(pc,d0.w)

= 32 cycles

qui t'économisera au passage 4*512=2 ko (2 octets pour le long et 2 pour la relocation)

et puis :
ext.w d0/ext.l d0/add.l d0,a5 => ext.w d0/add.w d0,a5


Extended> ça m'a l'air d'être de l'ASM

Pollux a écrit :
qui t'économisera au passage 4*512=2 ko (2 octets pour le long et 2 pour la relocation)

4*512-2 plutôt. jmp 0(pc,d0.w) prend 2 octets de plus que jmp (a0).

Pim89 a écrit :
ben Bravo, tu a l'air très bon en effet !

Pas exceptionellement. Vu l'abondance d'infos techniques sur le GameBoy n'importe qui avec un peu de volonté aurait pu programmer un truc pareil...

ExtendeD
a écrit : C'est du C ou de l'asm ?

Si, c'est de l'asm, mais il doit y avoir pas mal d'optimisations à faire, vu que j'ai pas trouvé de la bonne doc sur les cycles que prennent les instructions...

Toutefois, quand je publierai le source on pourra tous se jetter sur les optimisations, mais avant cela je vais:

- fixer la routine d'écriture des sprites (vous aurez du remarquer que quand un sprite sort de l'écran il aparait n'importe ou: dans d'autres écrans, sur du code, bref c'est bordelique)
- ajouter le layer "window" (il me faut un peu plus de doc à ce sujet)

J'y suis déjà en train de travailler, et ce sera prêt bientôt

Je me demande si tu ne ferais pas bien d'utiliser un librairie graphique telle que Xlib pour l'affichage, tu pourrais de cette façon très certainement accélérer pas mal l'émulateur

oui, mais il faudrait qu'il recopie les sources une à une dans le code alors, car Xlib n'est pas prévu pour l'ASM pur.

Comment ça n'importe quel lib prévue pour le C avec TIGCC peut sans le moindre problème s'utiliser en ASM, il suffit de connaître la convention de passage (celle de Xlib demande de passer les arguments par registre) !

Si TiMad nous fait un vrai fichier .a, alors oui. Mais pour l'instant, on a un paquet de .h avec des asm("") dedans.

ha !!!???
Alors *****X a déjà au moins 2 avantages sur Xlib

1- vraie lib en .a : l'utilisateur n'a rien à inclure à la main, le compilo se charge de n'intégrer que les fonctions utilisées au programme.
2- simplicité d'utilisation déconcertante (dans le sens positif)

l'utilisateur n'a rien a faire mis apart utiliser le générateur de projet ....

Tu parles pour Xlib ?

Tel que tu le dis, on pourrait croire alors que Xlib est facile à intégrer à un projet, mais en approfondissant, on se rend compte que :
- il faut, pour chaque projet l'utilisant, sélectionner puis copier les fichiers dont on a besoin
- en cas de nouvelle version de la lib, il faut alors regarder dans chacun de ses projets quels fichiers on utilise, aller chercher les nouvelles versions dans le nouveau package puis les copiers

...

Avec *****X, rien de tout ça ! (je dévoilerai le nom de *****X à sa sortie )

Et ça sort quand, *****X ?

jackiechan91
a écrit : Et ça sort quand, *****X ?

ds *****X années

Demain soir. Il me reste un dernier truc à régler sur les sprites masqués.

Thibaut a écrit :
- il faut, pour chaque projet l'utilisant, sélectionner puis copier les fichiers dont on a besoin
- en cas de nouvelle version de la lib, il faut alors regarder dans chacun de ses projets quels fichiers on utilise, aller chercher les nouvelles versions dans le nouveau package puis les copiers

Je vois vraiment pas pourquoi. Il suffit d'avoir un classeur tel /lib où l'on met toutes les librairies et on utilise l'option include path du compilateur, puis on linke avec la lib depuis tous les projets... si vous utilisez des Makefiles c'est couillon couillon

C'est quoi ta lib, encore une lib graphique?

Bon, je propose de l'appeler le projetX, parce qu'ils mettent partout (*****X)
Je ne fais aucune allusion douteuse, voyons