Émulateur de GameBoy pour TI - Page 6

Pollux a écrit :
Non, si tu le mets en static, il part dans le segment data, donc il est alloué statiquement même en mode kernel. Mais tu peux enlever le static sans pb

Ça, c'est un bogue de TIGCC qui sera corrigé dans la prochaine bêta.

ah bon??? j'étais pas au courant, va falloir que je modifie GTC

(enfin si tu dis pas de conneries )

Merde je me suis retrouvé avec un prog assez horrible. Apparament j'ai un address error avant que mon code commence à executer. J'ai mis

        even
_main   rts

et ça continue à planter. Je l'ai lancé sur db92 et ça donne un address error dans le "decompressing" puis (suite à appuyer entrée) je me retrouve dans l'écran principal de db92 mais sous code il y a rien.

Des idées?

Ça y est 'y avait un xdef en moins dans une lib

Je pense que cela foire doorsos...

DoorsOS

Utilise PreOs à la place...

Nouvelle version avec comme nouveauté cette histoire du LY (voir post précédent). J'ai aussi fait des optimisations de vitesse/place, avec des bons résultats en ce qui concerne la place et des moins bons en ce qui concerne la vitesse. Eh ouais, ça rame toujours...

08/01/2002 - v0.3.2

I'm trying to make it run faster but even after all these tweaks there are no
big speed improvements. Is there anything left before HLE?

- Remember that LY thing I was talking about in the changelog of the 0.2? Well
it's implemented , and to my surprise with very little slowdown (most of the
lcdlib API had to be restructured to make this possible). A Lot of stuff began
to show up properly, but some still doesn't.
- The setdeinit macro has been rewritten longjmp style: it restores SP and jumps
to deinit. Since this eliminates the need for self-modifying code the emu can
now *hopefully* be run multiple times whithout needing to retransmit.

- Replaced the mulus in lcdlib by faster shifts+additions.
- Made lcdlib use dynamic memory for its buffers. This reduced the size of the
lib by ~26k (and increased the free ram requirements by the same amount :^).
- Merged lcdlib (wich was renamed to lcd) and tigb (=faster calls).
- Moved the GameBoy A register (acumulator) to a 68k dataregister, with very
little speed improvement (a lot less than expected).
- Added compile option SAFE wich covers extra checks against buggy ROMs.
- Added compile option DIV wich allows to disable the divider register.
- Shorter and faster jumptables (.w instead of .l, reduced code ~1500 bytes).
- New getv16 wich uses a temporary register to speed things up (-4 cycles).
- Improved call routines (-10 cycles when the call is made, else -34 cycles).
- Push/call/rst.. (-22 cycles) and pop/ret/reti (-26 cycles).
- Added a separate macro to set the event handler instead of reseting it every
addev (-24 cycles per addev).
- IME as a mask that can be AND'd to IF (- a couple of cycles per cc overflow)
- Added a jumptable for interrupt acknowledging (from -10 to -40 cycles per
interrupt, depending on wich interrupt is taking place).

damned ! ça devient de mieux en mieux !

-

Boogerman : ça fait 20 ans qu'on te dit que tu pourrais augmenter la quantité de RAM libre en remplaçant l'utilisation de userlib@ngetchx par tios::ngetchx

Orion_ et Thibaut, j'avais oublié donc celle-ci est pour vous:

08/03/2002 - v0.3.3

- Fixed RAM not freed in lcdlib if grayon failed.
- Added a separate plane for debug (dbglcd) to lcd.asm. It takes ~4k more RAM,
but it is much nicer and the 'show LCD' feature (wich was broken in last
release) is working again.
- Replaced idle_loop by ngetchx (userlib is no longer required).
- Fixed instruction 'ld HL,SP+v8' wich was behaving like 'ld HL,HL+v8'. Lemmings
began to work properly, but Tetris still doesn't, so there are probably more
buggy instructions around.

non mais regardez, ms regardez moi ça:




bon, je lavoue, g grave accéléré lanimation ds animation shop, ms qd ^m!! g envie de tester sur calc, ms tigb est-il compatible 89? et hw2? si oui, je fonce....

-

le vient de la taille, ou de la beauté des jeux? ou encore de la lenteur??
moa g pa multiplié par 4 ms par 10....
joli le kirby! je vais en faire dautre, moa!

encore heureu ke shinobi nexiste pa sur GB.....

redangel17
a écrit : ms tigb est-il compatible 89? et hw2? si oui, je fonce....

Éh ben, normalement on n'aurait qu'a modifier la taille de l'écran pour le faire marcher sur 89. Toutefois, je te conseille pas de le faire, vu que l'emul plante quelques fois en sortant (c'est après le deinit, donc je pense que c'est doorsos le coupable, mais il se peut aussi bien que j'aie un memory leak).

Ce qui serait intéresant serait que ceux qui veulent aider s'y mettent dans le debugger (touche "mode") et suivent le code des les jeux qui déconnent jusqu'à trouver les instructions/choses qui ne marchent pas correctement. Un bon emul pour x86 qui a aussi un debugger (pour comparer) est GameLad.

se serait sympa que tu foutes des roms sur ton site à prête à foutre directement dans la ti, parce que c'est un bordel d'en trouver sur le net...y a plein de sites pour l'émulation mais aucun qui marche bien avec des roms...ou sinon orion et redangel mettez vos roms sur le ent svp

santi a écrit :
se serait sympa que tu foutes des roms sur ton site à prête à foutre directement dans la ti, parce que c'est un bordel d'en trouver sur le net...y a plein de sites pour l'émulation mais aucun qui marche bien avec des roms...ou sinon orion et redangel mettez vos roms sur le ent svp

Hors de question!

Je ne comprend pas rien ne se lance sur l'emu, j'ai une rom 2.05 de92+ et vti, de plus j'ai mis les rom decoupés dans bin, et tigb dans main, manque-t-il qqch, j'ai egalement mis uOS?
J'ai fait comme indiqué ca ne marche pas, j'ai oublié quoi, j'aimerais quand meme bien voir tourner ca!

freka> tu as tt faux! faut pa mettre les roms coupées ds un répertoire /bin sur la caltos! c unikement sur ton ordi ki faut faire com aç pr les convertir!
mets les morceaux du jeu ds main, ainsi ke tous les fichiers de lémul, et ça marchera

santi> je vais uploader mes qqls 15 roms de gb et je mets un lien ds 2s
ms g pa les meilleurs jeux de gb, dsl...
les roms st ttes petites!!

voilà pr moi:
http://redangel17.free.fr/Roms/

je vous conseille motocros!!

je vous déconseille turok2, il fait 1 méga, la caltos doit pa aimer...

Sur V200, à la limite, ça pourrait passer...

En ce qui concerne la taille, on pourait monter encore une abstraction sur sflib qui s'occuperait de la compression. Comme ça on pourrait avoir les ROMS comprimés (~40% de leur taille réelle). Existe-t-il des librairies de compression assez flexibles?

ttpack.

J'ai aussi eue une idée pour optimiser les jumptables: au lieu de sauver l'addresse relative du handler dans la table, on pourrait allouer de la RAM et copier chaque handler dans un bloc de taille fixe (=2^n t.q. 2^n>la taille du handler le plus grand) comme cela on ferait un asl #n,val et on jmp (addresse de la table des handlers,val). Bien sûr, cela boufferait trop de RAM. Qu'en pensez vous?

Kevin Kofler a écrit :
ttpack.

Comment fait-on pour lire un fichier ttpack on calc?

Avec la fonction UnpackBuffer dans extgraph.a.

boogerman> un lsl prend 6+2n cycles alors qu'un move.w 0(a0,d0.w),d0 en prend 14, donc c rentable pour n<4 soit des handlers de taille <=8

en plus, sauf si tes handlers sont tous assez petits, ça risque de bouffer plein de RAM

Il y aurai des possibilitées de voir une version TI89 de cet emu ou c impossible