Émulateur de GameBoy pour TI - Page 3

Hé ouai, on n'a pas de carte graphique dédiée au jeu ni assez de RAM.
C'est peut-être la GBA qui a un proc à 8MHz ?

en proc graphique ??

Pim89> un emu, c dur de bien le faire tourner .. regarde VTi sur ton PC (c peut-etre pas un bon exemple mais c'en est un !)

Nan en proc principal.

non , je crois que la GBA c'est plus (le proc est un 32 bits).

la GBA, c pas un proc à 16MHz ?

ou 24 Mhz ??? je sais plus trop ... j'avais lu ça aussi, vaut mieux pas s'y fier alors.

bien sûr l'idéal niveau vitesse (pas mémoire ) ce serait un convertisseur on-PC, avec un émulateur classique au cas où le code serait modifié en run-time

Il "suffirait" () de mettre toute la zone du code du programme à 0, puis dans l'ému, lorsqu'il exécute du code, il fait un tst.l (gameboy_pc) et si c nul, il exécute les 4 octets correspondants qui ont été pré-compilés en asm 68k

Le problème est qu'une ROM de 32ko demanderait au moins 64ko d'archive supplémentaire pour le code 68k A part ça ça promet d'être rapide (surtout si le pré-compilateur utilise un algorithme d'optimisation de l'asm (peephole optimisation), genre celui de GTC )

voué, pas con comme idée de précompiler le code en ASM68k sur PC avant !

Pim89 a écrit :
ah bon ??? je suis sur d'avoir lu sur un site que la GB avait un proc à 8 Mhz !! mais je veux bien te croire, le gars du site devait pas tout capter.

mais elle est aussi conçu pour le jeu, et pas la TI.

Souvenez vous que MegaDrive == Ti68k au niveau du proc, mais après, va faire tourner une rom de MD sur ti.

ET STREET OF RAGE III ALORS? ET SMA? ET SFII?
oui, il n'ya pa la couleur, ms déjà!!!!

Pollux> à priori génial!!! tu vs pa te mettre en relation avec le sieur booger? à moins ke vraiment tu ne codes plu....

je veux bien optimiser le moteur d'émulation qui va décider si il faut lancer le code 68k ou le code Z80, et je veux bien m'occuper de la partie relative à l'optimisation du code 68k pré-compilé (ie : une fois les instructions z80 transformées en 68k, on peut optimiser certains trucs dans l'enchaînement des instructions)

Mais d'abord il faut voir si c viable niveau mémoire, si boogerman veut bien passer du temps sur ce mode, etc... D'autant plus que j'imagine que mettre des 0 à la place du code ne conviendrait pas à tous les progs (genre addq.b #3,(code_location) -> ça foire puisqu'on peut pas le différencier de move.b #3,(code_location)), donc il faudrait garder une copie archivée et une copie en RAM du programme (mais a priori ça ne pose pas de problème puisque c déjà le cas, j'imagine)

Et puis il faudrait aussi détecter si une séquence d'instructions est susceptible de correspondre à du code réel (mais ça ça devrait pas être trop trop dur je pense)

Salut de nouveau. Veuillez excuser mon long silence, je suis un peu au cul du monde (en vacances) et l'acces internet n'est pas facile. Pas d'accents non plus (je suis sur un clavier de meeeerde

Le GB (normal) fait 4MHz CPU cycles / 1MHz inst cycles (les instructions prennent des temps multiple de 4 cycles). La TI-92+ fait 12MHz CPU / 3MHz cycles, donc ca fait 3 fois plus vite.

Cette histoire de recompilation est interessante (j' y avais deja pense), mais c'est pas du tout couillon a faire. Il y a des trucs tres merdiques, par exemple les jeux copient du code dans la high ram (>ff00) et puis l'executent (cela est du a ce que lorsque l'on fait du DMA on n'a pas access a la low ram). Il y a aussi pas mal de trucs qui sont horribles mais que je ne me souviens pas. En gros, on pourrait pas ecrire un recompilateur generique parce que les architectures sont tres differentes et cela donnerait des codes tres ineficients (meme plus que l'emul)

Pour l'instant je vais m'occuper de faire marcher l'emulateur a la perfection (ie: sans bug). Je suis en train de programmer des trucs interessants que je publierai quand je serai de retour chez moi.

Une fois que l'emul marchera correctement, je m'occuperai des ameillorations. Je pense que les choses qui peuvent s'ameillorer sont:

- Mettre le régistre A du GB dans un regristre de la TI (ce registre joue le role d'accumulateur et la plupart des operations mathematiques / acces memoire ne peuvent se faire qu'avec lui)
- Mettre le SP (stack pointer) du GB dans un registre de la TI
- Routine d'ecriture de l'ecran: plus de buffers intermediaires (ie: plus de RAM occupée) pour avoir moins a redessiner a chaque fois)
- Ameillorations dans le loop des instructions (c'est l'endroit du code ou les cycles gagnes sont les plus importants)
- HLE (reemplcer certaines fonctions par des equivalentes en 68k)

A +

>> Routine d'ecriture de l'ecran: plus de buffers intermediaires (ie: plus de RAM occupée) pour avoir moins a redessiner a chaque fois)

Tu devrais faire du "double buffering"

Pollux a écrit :
je veux bien optimiser le moteur d'émulation qui va décider si il faut lancer le code 68k ou le code Z80, et je veux bien m'occuper de la partie relative à l'optimisation du code 68k pré-compilé (ie : une fois les instructions z80 transformées en 68k, on peut optimiser certains trucs dans l'enchaînement des instructions)

Mais d'abord il faut voir si c viable niveau mémoire, si boogerman veut bien passer du temps sur ce mode, etc... D'autant plus que j'imagine que mettre des 0 à la place du code ne conviendrait pas à tous les progs (genre addq.b #3,(code_location) -> ça foire puisqu'on peut pas le différencier de move.b #3,(code_location)), donc il faudrait garder une copie archivée et une copie en RAM du programme (mais a priori ça ne pose pas de problème puisque c déjà le cas, j'imagine)
Et puis il faudrait aussi détecter si une séquence d'instructions est susceptible de correspondre à du code réel (mais ça ça devrait pas être trop trop dur je pense)

Thibaut a écrit :
>> Routine d'ecriture de l'ecran: plus de buffers intermediaires (ie: plus de RAM occupée) pour avoir moins a redessiner a chaque fois)

Tu devrais faire du "double buffering"

Je ne pensais pas a double buffering, mais a avoir plus des buffers pour sauver les sprites lis de la memoire du gb avant de leur appliquer la palette de couleurs. Un autre pour les sauver appres, etc... Il y a deja ce genre de truc dans mon code, mais pas assez...

Ajoute : xdef _readonly
dans le fichier rom. Si tu as les bons fichiers include, et si utilises preos, tu economiseras de la ram.

PpHd a écrit :
Ajoute : xdef _readonly dans le fichier rom. Si tu as les bons fichiers include, et si utilises preos, tu economiseras de la ram.

Si tu utilises TIGCC, ne rajoute par xdef _readonly (qui ne marchera pas), mais:
_flag_3: xdef _flag_3
C'est la même chose, mais dans le langage de Obj2Ti (qui prédate la version modifiée de MakePrgm par PpHd, donc c'est lui qui ne respecte pas les standards, pas nous ).

Et puis, c'est une idée stupide d'utiliser une librairie dynamique pour un fichier de données. Tu devrais mettre ta ROM dans un fichier de type personnalisé!

^^
Ne l'ecoute pas. Et puis ce N'EST PAS DOCUMENTE _flags_n, alors Kevin

PpHd a écrit :
^^
Ne l'ecoute pas. Et puis ce N'EST PAS DOCUMENTE _flags_n, alors Kevin

On en a parlé sur l'ancien forum, et tu y étais.

JM - posté 30 Mai 2001 12:31 - Editer - Citer - ICQ : n/a - IP

<<<
JM avait proposé d'ajouter une RAM CALL retournant l'handle de la sauvegarde de l'écran, c'est vrai que c'est pas une mauvaise idée.
>>>
Ce sera tout autre chose alors abandonnez tout ça, ça ne fera que poser des problèmes.
J'ai l'intention d'utiliser un flag parmi les 14 qui sont disponibles dans l'en-tête d'un programme doors. S'il ce flag est à un, le kernel ne sauve pas l'écran.
C'est fait.
Faut utiliser ce linker et la ligne :
_flag_2: xdef _flag_2
[Edité par JM (30 Mai 2001).]

puis quelques autres posts, puis:

PpHd - posté 05 Juin 2001 16:51 - Editer - Citer - ICQ : - IP

Et pourquoi _flag_2 ?
(En fait, c juste pour savoir pourquoi ce nom en particulier).

! Cassoulet party !



JM - posté 05 Juin 2001 17:23 - Editer - Citer - ICQ : n/a - IP

Juste parce qu'il y a 16 flags dont 14 inutilisés. A l'avenir, on n'aura pas besoin de modifier le linker pour utilser de nouveaux flags. Le linker reconnaît _flag_ et récupère le nombre indiqué juste après.


JM - posté 05 Juin 2001 17:24 - Editer - Citer - ICQ : n/a - IP

Quand ce sera sorti officiellement, on n'utilisera pas ce nom. Ce sont les .h qui contiendront les équivalences.
[Edité par JM (05 Juin 2001).]



PpHd - posté 05 Juin 2001 17:38 - Editer - Citer - ICQ : - IP

Ok. Et c quoi les autres flags ?

! Cassoulet party !



JM - posté 05 Juin 2001 20:39 - Editer - Citer - ICQ : n/a - IP

Pour rester compatible, _ti89 et _ti92plus sont encore supportés par le linker.
_flag_0 : 92+
_flag_1 : 89
_flag_2 : ben c'est le sujet du topic
_flag_3 à _flag_15 : inutilisés
_flag_16&+ : sans effet

Le dernier flag (_flag_15) pourrait ne pas être utilisable (doc de plusshell) :
"bit 15 - TI-89 emulation (force 89 screen size on 92+)"
Je ne sais pas s'il existe un kernel le gèrant ou des programmes ayant ce flag à 1.



PpHd - posté 06 Juin 2001 11:03 - Editer - Citer - ICQ : - IP

Je sais pas. Mais j'y crois pas.
Je crois que c'etait pour que Rusty teste ces programmes 89 sur 92.
! Cassoulet party !

Voilà. Alors ne me dis pas que tu n'étais pas au courant.

héhé, une chose à dire : ! Cassoulet party !

J'arrive tard, mais le lien ne marche plus

Kevin Kofler
a écrit : Et puis, c'est une idée stupide d'utiliser une librairie dynamique pour un fichier de données. Tu devrais mettre ta ROM dans un fichier de type personnalisé!

Tout a fait d'accord mais c'etait la facon la plus simple de le faire pour essayer.

Je prends l'avion de retour dans une heure, quand je serai chez moi je vais poster la nouvelle version qui utilise une librairie qui fait des fichiers splittes pour surpasser la limite de 65k et les lit comme s'ils en etaient un. J'ai aussi pas mal corrige de bugs. Et comme il y en a tellement a chaque bug que je corrige il doit y avoir une dizaine de jeux qui marchent mieux :^). Cette nouvelle version supporte aussi les roms de plus de 32k (MBC1).

Salut.

>Kevin: Moi je parle de documentation OFFICIELLE !

Bon je suis de retour chez moi, voilà le fruit des vacances

07/22/2002 - v0.2

A Lot of (important) bugfixes, but also some interesting new features, that's
why it gets a +1 in the minor version number. It's still alpha software, though
:^P

- Added support for MBC1 roms, by adding a split file library wich allows to
override the filesystem limit of 65k and to have the ROM in archive, thereby
taking no precious RAM. Any compression could run transparently on top of this
library allowing virtually any ROM to fit in the archive! (see the readme for
details on how to create these splitted ROMs)
- Made more flexible the RAM bank write enabling/disabling (before: $0a enables,
$00 disables, now $Xa enables and anything else disables). Anyway RAM is still
not supported so who cares anyway :^)
- Added the halt instruction.
- Fixed if register not writable.
- Fixed interrupt priority wrong (inverted).
- Fixed event list getting corrupted after two followed interrupt enabling
instructions (ie: ei and reti, ei and ei ...).
- Fixed interrupt selection by LCD status not working properly.
- Fixed ly=lyc flag and interrupt not being set when lyc=0.
- Fixed lyc register not writable.
- Changed the event library so that addev accepts an effective address as the
number of cycles (instead of only immediate values).
- Added the ability to run for n cycles to debug.
- Fixed a bug in the LCD update routine wich caused the background not to be
updated after a change in the background palette.

I also found some very ugly things in some games. Lemmings, for instance, keeps
two background buffers and at a certain LY swaps them, so that the screen above
that LY shows the 1st background and the screen below it shows the 2nd. To
emulate this kind of behaviour, we should do exactly as the GameBoy does: write
one line every LY, and update the buffers *instantly* when the data is modified
so that it is shown in the following LY (instead of drawing the whole thing at
every V-Blank). I don't even want to imagine how slow this would be!
Unfortunately, this whole LY thing is used to make a variety of video FX, so I
assume it is to be emulated correctly...

-

-

Si tu fais ce que demande Orion, n'oublie pas de verifier les registres avant.

Merci du changement Orion. Il parait que mon truc (%~ni) ne marche que sur le for de NT qui est plus puissant que celui de 9x

En ce qui concerne le idle_loop, quelles sont les différences entre un et l'autre?

Boogerman

Aucune il me semble.
Peut-être même que le idle_loop de userlib est redirigé sur la ROM_CALL ngetchx ?

oula, alorfs ne l'utilise pas si tu veux qq chose d'optimisé.
ngetchx() ralenti vraiment les programmes.