Émulateur de GameBoy pour TI - Page 16

Si tu le veux, je pourrais toujours essayer de te faire un moyen d'execution de ton emu dans la flash.

PpHd
a écrit : Si tu le veux, je pourrais toujours essayer de te faire un moyen d'execution de ton emu dans la flash.

J'ai bien reçu PedroM. Merci :^D

Je vais le tester dans cette semaine. Mais si ma mémoire est bonne, Kevin m'a dit que l'éxécution depuis la flash était plus lente. Peux tu confirmer ceci? Sais-tu de combien?

Je viens de tester vite-fait pour voir si ça marche et ça me plante la calc. J'ai donc mis un rts au tout début de mon _main, et ça continue à planter. On dirait qu'il n'en arrive même pas.

Je vais faire un test sur AMS+PreOS (car à présent j'utilise DoorsOS), mais là j'ai plus le temps. En tout cas j'ai joué un peu avec PedroM et je peux pour le moins te dire que ça promet .

boogerman
a écrit : Je viens de tester vite-fait pour voir si ça marche et ça me plante la calc. J'ai donc mis un rts au tout début de mon _main, et ça continue à planter. On dirait qu'il n'en arrive même pas.

Normal, il y a une protection anti-exécution (et cela sur HW1 comme sur HW2). Il faut la désactiver, mais c'est de la même difficulté que le HW2Patch (qui fait la même chose pour la protection anti-exécution de la RAM des HW2).

C.à.d. qu'il faut que je lance hw2patch sur PedroM?

Pas sur Pedrom. Mais je pense que VTI n'émule pas correctement la déprotection de la protection anti-exécution en FlashROM, donc peut-être que ton problème est là.

PpHd peux tu nous eclaircir sur ce sujet?

As-tu netoyer la calc avant d'executer pour la seconde fois ton programme ? (Commande clean).
Y'a pas besoin d'hw2patch sur PedroM.
Et Kevin parlait de la protection sur vrai calc. L'as-tu essaye sur vrai calc ?

PpHd a écrit :
As-tu netoyer la calc avant d'executer pour la seconde fois ton programme ? (Commande clean).

Euh non. Lorsque j'éxecute mon prog pour la première fois ça plante. Il n'y a pas de seconde fois. En tout cas j'ai essayé de faire clean avant, mais ça n'a rien changé. Elle est censé faire quoi cette commande?

Y'a pas besoin d'hw2patch sur PedroM. Et Kevin parlait de la protection sur vrai calc. L'as-tu essaye sur vrai calc ?

Non j'ai essayé sur VTI. Même si je suis très confident sur la stabilité de mon prog (il ne m'a jamais planté sur VTI), je trouve injustifié de l'essayer dans la calc, vu la vitesse dérisoire à laquelle il marcherait.

Je veux dire la fois avec la commande rts seule (Je conseille plutot un "bra *"), est-ce juste apres que la premiere fois ca est crashe ?

Non j'ai l'habitude de faire un load state tjs avant d'éxécuter. C.à.d. la calc était clean.

N'oublie pas que je n'ai jamais essayé mon ému sur autre chose que sur Doorsos. Qq'un sait si ca marche sur d'autres kernels (notament PreOS)?

DoorsOS!?!

-

Nouvelle version. Vous pouvez la télechager sur http://www.boogersoft.com/projects/tigb comme d'hab.

Cette version ne présente pas de changements importants en ce qui concerne l'émulateur, mais elle ajoute support pour du code récompilé, comme j'en ai déjà parlé tt à l'heure. Pour ceux qui veulent tester le récompilateur j'ai ajouté une section très détaillée au readme (2.3 - Recompiler) qui explique comment s'en servir. Si qq chose n'est pas claire (l'anglais, c'est ahhhhhh) je suis prêt à répondre vos questions.

Voilà le changelog:

03/14/2003 - v0.5.0

This version adds support for statically recompiled code. This should become a
dynamic recompiler somewhere in the future, but for now it is only intended for
developpers. The mechanism for stating executed code is also different (much
more accurate). Please check the readme for information on how to recompile code
for your favorite game.

- Rewrote the call stat feature so that instead of stating function calls it
stats instruction executions. This requires *huge* amounts of RAM, but gives a
much better idea of what would be good to recompile.
- Optimized 'ld A,($FF00+C)' inst (-8 cycles).
- Made all invalid opcodes have the same handler (-160 bytes).
- Dasm.asm was being compiled even with debug disabled. I fixed that so now the
emu takes 6162 bytes less when debug is disabled. As a consequence Hexlib is
also no longer needed when debug is disabled, wich saves another 981 bytes.
- Some optimizations to the flag altering/setting macros.
- Optimized copying the Z80 C flag to the 68K X flag (-32 to -38 cycles in insts
'rl (hl)', 'rl r8', 'rla', 'rr (hl)', 'rr r8' and 'rra', -14 to -20 cycles in
insts 'adc (hl)', 'adc r8', 'adc v8', 'sbc (hl)', 'sbc r8' and 'sbc v8', and
-468 bytes in the tigb binary).
- Optimized 'pop r16' (-6 cycles).
- Merged all audio-related io register handler into one (-40 bytes).
- Rewrote the HW2 ROM copy routine as a loop, thus saving 3116 bytes at the cost
of a 4% slowdown (3090 cycles). What a deal.
- Rewrote the HW1 ROM copy routine to use bigger loops (= less dbras), wich is
now 41% faster (-35840 cycles) at the cost of a 16 byte larger binary. Another
great deal.
- Optimized macro SetSHfr (-6 cycles average, -140 bytes).
- Now the default compile options are debug disabled (wich suppresses the need
for hexlib and considerably reduces the binary size), and a frameskip of 2
(I got tired of people saying 'that thing is damn slow' :^P ).

a lala a quand FFL ou FFA sur TI...
serieusement bravo, c du bon et bo boulot

j'ai essayé la nouvelle version, toujours aussi impressionant, re bravo.
c'est dommage que se soit pas plus accésible la recompilation, j'aimerai bien testé un jeu recompilé pour voir ce que ça donne. y a pas moyen de simplifier le truc ?

C'est vrai que c'est pas simple du tout. L'idée es que, si la récompilation prouve valoir le coup, chaqu'un fasse le boulot une seule fois par jeu, m'envoie son game.offset et je l'ajoute à la distribution. Comme ça, le reste n'aurait qu'à éxecuter une seule commande.

En tout cas, le gain en vitesse n'est pas considérable pour l'instant, donc tu perds pas grand chose...

En cherchant je ne me souviens plus quoi dans un site d'émulation, je suis tombé sur TEZXAS (http://tezxas.ticalc.org/) qui est un émulateur de ZX Spectrum pour les TI-89/92. J'ai pas encore essayé l'ému, mais je suis tout de suite allé vers le lien "technical items" et je me suis rétrouvé avec une idée très intéressante:

Si vous avez suivi ce thread, vous devez être au courant qu'une des idées pour éxecuter les instructions était de localiser les handlers tous les 256 octets. De cette façon le saut serait:

move.b (a0)+,d0   ;a0 est le pseudo PC du z80
asl.w #8,d0
jmp offset(PC,d0.w)     ;offset pointe vers l'instruction qui se trouve au milieu

.
mais on avait tout de suite réjeté cette idée parce que les rotations sur 68000 sont très leeeeeeentes (6+2n=22 cycles) et en plus ça prenait trop de place (128ko pour les 2*256 instructions du Z80).

Pourtant, dans document mentioné (sur le site de TEZXAS), l'auteur propose de placer les handlers tous les 256 octets, et sauter avec un truc du genre:

                  move.b (a0)+,offseta1-offsetjmp+1(a1)
offsetjmp     jmp ($0000,a1)

.
Eh oui c'est du self modifying code. La valeur $0000 se transforme en (a0)<<8
Ce code ne prend que 26 cycles. En plus, l'auteur propose de mettre les deux tables ensemble. Pour la deuxiéme table, la valeur serait $0080. Donc on aurait 128 octets par instruction, et le binaire ferait 64ko.

Mon code de saut actuel fait 44 cycles. Donc en gros ça irait 2 fois plus vite. Bien sûr, comme inconvénient, il faut programmer un "loader" qui crée la table en mémoire. En plus, cette table ferait 64ko, c'est qui n'est pas du tout négligeable. En tout cas, je trouve que c'est un gain important en vitesse et que ça vaut le coup d'essayer.

Bien sur, je n'ai pas le temps à présent, mais dans un futur proche... En tout cas, avez vous pigé qq. ch. à ce que je raconte? Qu'en pensez vous?

Ben si c'est plus rapide, c'est mieux
Mais sinon, je ne comprends pas pourquoi il faut faire ce saut tous les 256 octets... Tu veux dire que pour chaque instruction, tu te donnes 256 octets pour l'émuler et après tu passes à l'instruction suivante ?

Si la vitesse de l'emu est 2 fois plus rapide alors il ne faut pas hésiter à essayer cette méthode même si il y a une perte en mémoire.

je suis du même avis, je suis prêt à sacrifier autant de mémoire qu'il faudra pour que l'émulateur soi plus rapide

je suis d'accord aussi

Je vient de tester ce prog : c'est Impressionant !
Une fois la vitesse amelioré il sera vraiment parfai.

Mais si il est possible d'emuler des programme de GameBoy, il est possible d'émuler les TI-83...? Mais bon c'est juste à titre d'information quoi qu'il faut créer la table des RomCalls?

geogeo
a écrit : Mais si il est possible d'emuler des programme de GameBoy, il est possible d'émuler les TI-83...? Mais bon c'est juste à titre d'information quoi qu'il faut créer la table des RomCalls?

Pour la table des ROM calls, je pense qu'il suffirait de copier la ROM...

Le z80 qu'utilise le Gameboy est un z80 modifié. Les régistres IX et IY n'éxistent pas, pas mal d'instructions ne sont pas présentes (nottament, celles qui travaillent avec les régistres IX et IY) et il existent qqs instructions en plus. Donc déjà pour émuler un vrai z80 (comme celui des TIs) il faudrait pas mal modifier le core de l'ému. Reste à savoir si la taille de la RAM/ROM de la TI-83 est suffissament petite pour entrer dans la RAM/ROM de la TI-89/92...

En tout cas, quel est l'intêret d'émuler une calc plus ancienne, donc moins puissante? (je connais pas la TI-83)

geogeo a écrit :
Si la vitesse de l'emu est 2 fois plus rapide alors il ne faut pas hésiter à essayer cette méthode même si il y a une perte en mémoire.

Ca fera pas 2 fois plus rapide, car ce que l'on réduit à moitié c'est le code de saut. Le reste des instructions reste comme il est. Ca devrait quand même faire entre 25%-50% plus vite.

bah...c tjrs ça
non ?

Bas 50% ça serat quand même un gain important en vitesse!

boogerman
a écrit : En tout cas, quel est l'intêret d'émuler une calc plus ancienne, donc moins puissante? (je connais pas la TI-83)

Ca multiplierait la bibliothèque de programmes !

Sur TI86, il existe des émulateurs pour TI82, TI83 et TI85, on a jamais fini de faire tourner des programmes sur cette calc.

Encore une nouvelle version. Cette fois ci il n'y a rien d'intéressant. Je voulais juste établir un checkpoint pour commencer avec les optimisations dont je vous ai déjà parlé.

Voici le changelog (vous pouvez le télécharger chez http://www.boogersoft.com/projects/tigb, comme d'hab'):

04/27/2003 - v0.5.1

No big changes but I'm about to attempt some optimizations that will require big
code modifications and I'd also like to rewrite the recompiler (to allow higher
level optimizations). So, this release only takes place to become some sort of a
"checkpoint".

- Fixed romsplit.exe so that it puts 7 half banks per file (instead of 6), wich
  allows 512k roms to be splitted into 10 files (instead of 11).
- Reduced ram write jump tables from word to byte (-256 bytes).
- Some 'move.b #0,dst' -> 'clr.b dst'.
- Moved almost all internal variables to dynamic memory. This reduced the binary
  by ~650 bytes (and increased memory requirement by that amount), but most
  importantly freed another address register (wich was pointing to the internal
  variable area), since now the same address register used for the GameBoy RAM
  is used for variables. I haven't yet figured out what I will be using that
  address register for. Please note that to acomplish this I had to modify
  almost every module of the emu, so I would like to be informed of any
  regressions.
- Recompiler optimizations: ASSUME_CALL_DONT_USE_FLAGS (assume function don't
  use caller's flags) and ASSUME_RET_DONT_USE_FLAGS (assume caller don't use
  functions flags).