Émulateur de GameBoy pour TI - Page 10

bon donc, si je résume, les pb du HLE, c :
- c chaud de détecter le code
- c chiant pour le code copié en mémoire haute
- c chiant pour le code auto-modifiant

S'il n'y a que ça, à mon avis la meilleure solution est d'avoir un mode Profile pour l'ému, dans lequel il stocke toutes les séquences d'instructions exécutées avec leurs adresses; ensuite, on remet ça sur PC, où un prog fait la conversion ASM Z80->68k, puis dans l'ému, il regarde si le PC correspond à une routine convertie, vérifie que le code correspond bien (et éventuellement stocke la probabilité de correspondance, de manière à ce que les zones qui ne sont jamais modifiées aient une proba de 100% et donc soient plus rapides d'exécution en mode rapide), puis exécute le code 68k si c possible.

A mon avis ça peut se faire

Toujours en cherchant à optimser...

J'ai trouvé (je pense) pourquoi Lemmings (et certainement pas mal d'autres jeux) rame tellement. D'après ce que j'ai vu, le code est tellement réparti dans toute la ROM qu'il n'arrête pas d'échanger les ROM banks (plusieures fois par frame!!!!). Cela force à récopier 16ko à chaque échange de ROM bank. En plus, les données d'origine ne sont pas forcément alignées à mot (ce qui nous force à copier octet à octet), et en plus il se peut qu'un ROM bank soit distribué dans plusieurs fichiers (cf: sflib) donc il faut faire quelques calculs avant la copie.

Conclusion: sflib ne va plus, 'faut absolument s'en débarasser.

Bon, je connais le format des fichiers dans la calculatrice, mais il me faudrait le format du .9x*, ou un utilitaire qui transforme un binaire en un .9x*. Quelqu'un peut m'aider? Merci!

-

Orion_
a écrit : prend: ttbin2oth

Superbe merci!

TIOS de meeeerde

RAM free: 153590
Flash ROM free: 392896

J'essaye d'archiver un fichier de 32Ko et il me dit:
"Can't archive: mainroma
Memory"

Peut être que si je lui branche les 256Mo de mon PC ça lui suffira?

TI

Solutions/workarounds bienvenus.

c bizarre
qd tu archives d'autres fichiers ça te met la même chose ?

quelle rom?

janjan2
a écrit : quelle rom?

C' est la version 2.05 (HW2) sur VTI, avec Doorsos. J' ai essaye d'uploader 16 fichiers de 32ko, et il ne me laisse pas uploader plus de 9 (j'ai foire cabri geometry pour me faire de la place). J'avais un probleme similaire avec le format sflib (fichiers de 65ko) mais en essayant plusieures fois ca marchait. Mais ici je reussis pas.

tu peux essayer de désarchiver un autre fichier un peu plus petit, archiver ton fichier puis réarchiver l'autre (ça vient de l'algo de garbage qui doit pas être parfait, loin de là)

Si tes fichiers font plus de 32768 octets, c normal puisque le tios ne peut pas caser 2 fichiers dans le même secteur... (pour être exact 64 ko - 2*18 octets de header de fichiers - 4 octets de header de secteur = 65496 donc tu peux pas avoir plus de 32748 octets par fichier, et moins si tu enlèves le header de fichier et le tag OTH...)

hwti
a écrit : tu peux essayer de désarchiver un autre fichier un peu plus petit, archiver ton fichier puis réarchiver l'autre (ça vient de l'algo de garbage qui doit pas être parfait, loin de là)

J'ai deja tout efface! J'ai meme fait un reset de l'archive!

Pollux
a écrit : Si tes fichiers font plus de 32768 octets, c normal puisque le tios ne peut pas caser 2 fichiers dans le même secteur... (pour être exact 64 ko - 2*18 octets de header de fichiers - 4 octets de header de secteur = 65496 donc tu peux pas avoir plus de 32748 octets par fichier, et moins si tu enlèves le header de fichier et le tag OTH...)

Je vois pas pourquoi. Avec l'ancien format (fichiers de 65ko) ca marchait parfaitement.

Superbe travail Boogerman!
Au sujet de l'adaptation sur 89, il me semble que l'ecran de la gb est + grand que celui de la 89, non?
Dans ce cas, l'adaptation risque d'etre compromise...

Si ca peut vous aider, il y a une equipe de codeurs atari encore tres active qui a fait un emu gb pour atari falcon
c un 68030 à 16 Mhz qui ressemble donc fort au 68000.
Apparement il ont transposer en 68030, faudrait verifier.
pour l'adresse :
http://www.reservoir-gods.com/emulate.htm

Pegasus a écrit :
Superbe travail Boogerman!
Au sujet de l'adaptation sur 89, il me semble que l'ecran de la gb est + grand que celui de la 89, non?
Dans ce cas, l'adaptation risque d'etre compromise...

Eh ben l'ecran es deja plus grand que celui de la TI-92 (16 pixels verticalement, le display du GB fait 160*144)

Si ca peut vous aider, il y a une equipe de codeurs atari encore tres active qui a fait un emu gb pour atari falcon
c un 68030 à 16 Mhz qui ressemble donc fort au 68000.
Apparement il ont transposer en 68030, faudrait verifier.
pour l'adresse :
http://www.reservoir-gods.com/emulate.htm

J' y jetterai un coup d'oeil merci!

Maintenant j'ai essayé avec des fichiers de 16ko (au lieu de 32) et maintenant ça plante au 20ème fichier (tout à l'heure ça plantait au 10ème). Aurait-ce quelque relation avec la taille? Je vois pas trop pourquoi vu qu'avec 7 fichiers de 65ko ça marchait niquel.

Passons donc aux grands moyens: celui qui réussit à mettre les 16 fichiers que je publie ici: http://www.boogersoft.com/projects/tigb/challenge dans l'archive de VTI 92+ et m'envoie un savestate gagne un bouquet de fleurs (si vous voulez le faire gratos ce serait pas mal non plus).

j'y arrive pas..ça me fait même planté la calculatrice parfois (enfin VTI)

Le port 89 est presque prêt, avec pas mal d'améillorations importantes (dont la disparition de sflib). Il me faut d'une part une solution à cette histoire des fichiers dans l'archive, et d'autre part j'ai constaté que, même si le display de la TI-89 est de 160*100 pixels, on dirait qu'il est de la même taille que celui de la TI-92 (240*128 pixels, 3840 octets) et que seuls les premièrs 160 pixels pixels de chaque ligne sont visibles et que seules les premières 100 lignes sont visibles. Quelqu'un peut me confirmer que cela est vrai pour toutes les TI-89? D'autre part, peut on écrire impunément dans le reste de l'écran (ie: la partie non visible)?

À +

oui l'ecran 89 et 92+ est le meme et seul une partie est affichee sur 89
et tu peut ecrire sur le reste avec toutes les 89 tu risque rien

c bien ce qui me semblait, je réexplique :

avant, tu utilisais des fichiers de 64 ko - epsilon, qui tiennent donc chacun dans un secteur de Flash

maintenant, tu utilises des fichiers de 32 ko + epsilon, et si tu pouvais en mettre plus de 2 par secteur, alors tes secteurs feraient 64 ko + 2*epsilon, or ils font moins de 64 ko : donc tu ne peux en mettre qu'un par secteur... et comme tu as 10 secteurs (en fait 11, mais le 11è est pour les FlashApps seulement), eh ben tu peux mettre que 10 fichiers...

Par contre ce que je comprends pas c pourquoi tu peux mettre que 20 fichiers de 16k et pas 30...

Pollux a écrit :
c bien ce qui me semblait, je réexplique :

avant, tu utilisais des fichiers de 64 ko - epsilon, qui tiennent donc chacun dans un secteur de Flash

maintenant, tu utilises des fichiers de 32 ko + epsilon, et si tu pouvais en mettre plus de 2 par secteur, alors tes secteurs feraient 64 ko + 2*epsilon, or ils font moins de 64 ko : donc tu ne peux en mettre qu'un par secteur... et comme tu as 10 secteurs (en fait 11, mais le 11è est pour les FlashApps seulement), eh ben tu peux mettre que 10 fichiers...
Par contre ce que je comprends pas c pourquoi tu peux mettre que 20 fichiers de 16k et pas 30...

Merci pollux, j'avais pas compris ce que tu voulais dire. Donc on est totalement dans la merde. Il faut absolument ne pas splitter les ROM banks en deux fichiers car ça fait lent. J'ai trop gagné en vitesse avec la nouvelle methode et je veux pas faire marche arrière. Mes premiers fichiers n'étaient pas de 65ko+epsilon mais de 65ko exact (65536) (en réalite quelques bytes en moins). Des fichiers de 65ko entiers pour moi (ie: sans taille.w et sans marque de fin) m'arrangeraient bien: existe-t-il un moyen de marquer un secteur comme occupé et s'en servir RAW?

Avec des fichier de 48ko, zelda fait 11 fichiers, ce qui ne rentre pas non plus.

De même avec les fichiers de 16ko. À 3 fichiers par secteur ça fait 11 secteurs (même si tout à l'heure ça plantait avant d'y arriver).

Là, j'sais plus que faire...

> Mes premiers fichiers n'étaient pas de 65ko+epsilon mais de 65ko exact (65536) (en réalite quelques bytes en moins).
Oui, c pour ça que j'ai dit moins epsilon de toutes façons un handle ne peut pas dépasser 65520 octets

> Des fichiers de 65ko entiers pour moi (ie: sans taille.w et sans marque de fin) m'arrangeraient bien: existe-t-il un moyen de marquer un secteur comme occupé et s'en servir RAW?
J'imagine bien que ça t'arrangerait
Mais c pas possible car il faut un header pour dire au TIOS que c occupé (4 octets )
Le seul moyen serait de faire un MinMem (le contraire de MaxMem ), mais ça serait pas compatible V200... Sinon tu peux faire une app flash


Tu peux essayer avec des fichiers de 56 ko si ça ralentit pas trop, mais il faudrait 9 secteurs + 8 ko, donc plus bcp de place pour l'ému (56 ko)

Pollux a écrit :
Tu peux essayer avec des fichiers de 56 ko si ça ralentit pas trop, mais il faudrait 9 secteurs + 8 ko, donc plus bcp de place pour l'ému (56 ko)

Eh ben tant pis. Faudra tout effacer pour jouer aux grands jeux. Je fais 56ko et si l'on pense à quelque chose de mieux je le change. En tout cas, on peut déjà dire adieu à la compression à cause du bessoin de vitesse.

08/23/2002 - v0.4.0

Some very interesting speed improvements and features. The door is left open for
HLE... I've also been reading stuff about Dynamic Recompilation. Whether this is
viable or not in this project is still to be investigated...

- Disabled by default emulation of the S flag but left it as a compile option
(SFLAG). Since there is no instruction using this flag, the only way to read
it would be to push AF, pop it into some other reg and test bit #5. I would be
really surprised to see a game do this, so we'd better save the CPU cycles for
something else.
- Usually GameBoy games refresh the OAM (Object Attribute Memory) using a DMA
operation once every V-Blank, regardless of whether it has changed or not.
This was causing unnecessary buffer updates, so I fixed DMA so that it only
sets the rupdtob flag if the new data differs from the old data.
- Improved calls to lcdupdt (jsr lcdupdt + rts -> bra lcdupdt: -8 cycles per
H-Blank).
- Improved inclycp/setlyc (-8 cycles per H-Blank, -12 cycles per V-Blank).
- Fixed one-register movems in rom.h being automatically converted to moves
by A68k wich caused the Z flag to be cleared (even when an error was to be
reported). Replaced all other one-register movems in the project by moves in
the sake of clarity.
- Improvement to rom.h so that if the game tries to load a ROM bank already
loaded no action is taken.
- Added ability to log Z80 function calls, usefull find the more frequently
called functions and the HLE'em. This can be enabled with the new CSTAT option
in defs.h (more documentation on this feature will be available with the next
version wich *should* support HLE).
- Fixed excedent loops (dbra ending at -1 instead of 0) in lcd.asm (lcd_lcdoff
and bg_draw).
- Now the whole LCD is cleared when the emu starts, and when the LCD is turned
off by the game only the area corresponding to the GameBoy LCD is cleared
(don't bother).
- Changed ramw8 so that it is a macro instead of a function (saves 2 cycles per
RAM write operation).
- Added macro earamw8 wich takes 10 less cycles that ramw8 (every instruction
that writes to the RAM benefits from this) (in 16 bit instructions only the
first write uses earamw8, the 2nd write uses ramw8).
- Added one handler for each non special io write, enlarging the binary by ~1k
but reducing 10 cycles every io write operation.
- Added macro iow8 (similar to ramw8) wich improves 'ldh %v,a' and 'ldh c,a'
(-6 cycles).
- Replaced sflib by rom.asm wich provides word aligned ROM banks, allowing
faster ROM bank switching (~-290000 cycles, 5 times faster), and hence
considerably improving the speed of games doing a lot of switching. The only
drawback is that you will have to reconvert your ROMS to the new format.
- Improved halt instruction so that instead of decrementing cc until it reaches
zero it directly clears it and do ccoflow, saving some cycles.
- Reduced by 16 cycles write operations to the internal RAM and to the echo of
the internal RAM by replacing add.l/sub.l by add.w/sub.w.
- Fixed bug in macro palap in lcd.asm wich was not causing problems because the
macro is allways called with the .l suffix.
- Added ability to scroll the GameBoy LCD up and down, showing the 16 lines (44
in the TI-89) that don't fit in the screen.
- Did I write TI-89 in the last point? Oh well, I almost forgot :^P added TI-89
support (Thanks Redangel17 for sending me the TI-89 ROMs needed to make this
possible) (rom2ti now takes a 2nd argument wich is either 89 or 92).

-

même soucis avec Mario,mais j'ai pas poussé les tests plus loin.

santi
a écrit : même soucis avec Mario,mais j'ai pas poussé les tests plus loin.

Essayez d'autres jeux.

Jeux qui marchent: tetris, lemmings, zelda

L'instruction DAA (BCD) n'est pas emulée donc tous les jeux qui l'utilisent vont sortir de l'emulateur. Supporter cette instruction n'est pas facile car elle à bessoin du flag Half carry qui n'est pas présent dans le 68000. Il faudrait pour émuler le HC faire un asl #4, faire l'operation deux fois en sauvant le C comme HC, ce qui ferait très très lent.

Toutefois, je suis en train de travailler dans un fix pour cela (j'espère).

-

Orion_
a écrit : Boogerman > heu, mais mario fonctionnait nikel avant, alors p koi plus maintenant ?

Ah bon? Je pensais que tu parlais de Mario Land 2 (qui, en effect, plante à cause du DAA)

De quel mario parles tu?

je sais pas duquel parle orion, mais moi j'ai testé avec le mario que j'ai trouvé sur le site de redangel17 (page 6 de ce topic).