Émulateur de GameBoy pour TI - Page 4

-

erf, dsl , de toute façon c'est la même action produite si doorsos appelle la ROM_CALL ngetchx

pour le débugger ?? arf ok, c'est bon alors.

Pim89 a écrit :
erf, dsl , de toute façon c'est la même action produite si doorsos appelle la ROM_CALL ngetchx

pour le débugger ?? arf ok, c'est bon alors.

Ouais, c'est dans le debugger. On s'en fout si ça ralentit. C'est pas le bon endroit pour faire des optimisations.

Bon je pense que pendant ~1 mois je ne vais pas pouvoir travailler sur TIGB à cause d'un travail d'AI que l'on va présenter dans la fac. J'y jetterai quand même un coup d'oeil de temps à autre dans le forum...

Au sujet du grayscale, il me faudrait un peu plus de doc sur gray.s (paramètres, régistres détruits, autres précautions, etc...). J'y ai fait un petit essai et je me suis retrouvé avec un horrible address error, probablement parce que gray fait un alloc qq part et cela déplace ce que j'ai alloqué moi même, mais je suis pas certain...

Kevin, peux tu m'éclaircir à ce sujet?

-

boogerman
a écrit : Au sujet du grayscale, il me faudrait un peu plus de doc sur gray.s

Tout est dans la doc de TIGCC.

(paramètres,

Aucun.

régistres détruits,

d0, d1, d2, a0, a1 comme d'habitude.

autres précautions,

?
Je ne vois pas d'autres précautions à respecter.

J'y ai fait un petit essai et je me suis retrouvé avec un horrible address error, probablement parce que gray fait un alloc qq part et cela déplace ce que j'ai alloqué moi même, mais je suis pas certain...

Ben oui, gray.s alloue de la mémoire. Où veux-tu qu'elle mette les 2 plans pour les niveaux de gris sinon?

Orion_ a écrit :
>"gray.s" ???? utilise graphlib, c super simple

Ce n'est pratiquement pas différent de gray.s. gray.s a aussi des fonctions de double-buffering en plus, mais tant qu'on ne les utilise pas, ça se comporte exactement de la même manière que graphlib.

y'a toute les indication et toute les sources dedans

Pour gray.s aussi.

Et si on utilise gray.s plutôt que graphlib, ça fait une librairie dynamique requise en moins. On économise aussi de la RAM (gray.s est plus petite que graphlib parce que graphlib contient plein de fonctions inutiles qui n'ont aucun rapport avec les niveaux de gris et qui ne font que réimplémenter des ROM_CALLs). Et ça facilitera le futur passage à un mode de programmation propre (_nostub).

Et au fait: graphlib alloue aussi de la mémoire pour les plans, il n'y a aucune différence de ce point de vue-là.

-

Orion_ a écrit :
sauf que son emulateur utilise deja graphlib, donc, sa serait bete d'utiliser gray.s alors que c déja inclus dans graphlib

Vrai, mais si on désactive le debug (ce qui sera le cas lorsque le produit sera terminé) on n'a plus bessoin de graphlib...

D'ailleurs, tant qu'on n'utilise pas le double-buffering de gray.s, les fonctions sont tellement semblables que tu peux faire des equates pour utiliser graphlib ou gray.s en fonction du mode debug activé ou désactivé.

(L'interface des niveaux de gris sans double-buffering est toute bête: une fonction pour les activer, une autre pour les désactiver, une variable globale pour le plan foncé et une variable globale pour le plan clair. Et ceci indépendamment de la librairie choisie parmis TIGCCLIB, graphlib et gray4lib.)

J'arrive pas a faire marcher ce satané gray

Voila mon prog de test:


include "doorsos.h"
include "userlib.h"

xdef _ti92plus
xdef _main
xdef _comment

plane0 equ __D_plane
plane1 equ __L_plane

even
_main
movem.l d0-d2/a0-a1,-(a7)
jsr GrayOn
tst.w d0
movem.l (a7)+,d0-d2/a0-a1
beq bye

;quoique je mette ici sauf un jsr userlib::idle_loop plante la calc
;(address error, line 1111)
;
;par exemple: move.l plane0(PC),a0 -> address error

jsr userlib::idle_loop

movem.l d0-d2/a0-a1,-(a7)
jsr GrayOff
movem.l (a7)+,d0-d2/a0-a1

bye rts

_comment
dc.b "Graytest",0

end

Mais pourquoi tu sauvegardes-restaures d0-d2/a0-a1 pour appeler les fonctions de niveaux de gris ???? c'est du gaspillage de place et de temps ! je te rappelle que conformément à la convention C sur TI, le TIOS supporte qu'un programme détruise d0-d2/a0-a1.


Le plantage, à mon avis, est dû au fait que tu adresses les pointeurs __D_plane et __L_plane relativement au PC => retir le (pc), ça devrait mieux marcher

Non, ça devrait marcher en PC-relatif normalement! (On peut aussi utiliser bsr GrayOn à la place de jsr GrayOn.) Sinon, c'est peut-être un bogue du système de linking. Essaye quand-même de retirer le (PC), et si ça marche, je vais devoir vérifier d'où vient le problème (si le problème se résout en retirant le (PC), ça ne vient pas de ton programme, mais de notre système de linking).

Thibaut a écrit :
Mais pourquoi tu sauvegardes-restaures d0-d2/a0-a1 pour appeler les fonctions de niveaux de gris ???? c'est du gaspillage de place et de temps ! je te rappelle que conformément à la convention C sur TI, le TIOS supporte qu'un programme détruise d0-d2/a0-a1.


Le plantage, à mon avis, est dû au fait que tu adresses les pointeurs __D_plane et __L_plane relativement au PC => retir le (pc), ça devrait mieux marcher

Merci Thibaut ça marche niquel. Je suis vraiment pas habitúe a cette histoire de pointeurs relatifs. Quand est-ce qu'il faut utiliser machin(PC) et quand machin tout seul?

Kevin Kofler a écrit :
Non, ça devrait marcher en PC-relatif normalement! (On peut aussi utiliser bsr GrayOn à la place de jsr GrayOn.) Sinon, c'est peut-être un bogue du système de linking. Essaye quand-même de retirer le (PC), et si ça marche, je vais devoir vérifier d'où vient le problème (si le problème se résout en retirant le (PC), ça ne vient pas de ton programme, mais de notre système de linking).

J'ai retire le PC et ça marche, mais j'utilise a68k et le link de doorsos, donc je crois pas que ce soit la faute de tigcc (car je ne m'en sers pas)

Au fait, j'ai voulu m'en servir, mais j'ai pas trouvé quelle est la syntaxe pour linker sur CMD. Lorsque je fais gcc fichier1.o fichier2.o il me dit could not find ld.exe check that it is correctly installed ou un truc du genre.

Au fait, que se passe-t-il is je fais des HeapAllocHigh après avoir appelé GrayOn. Ça risque pas de déplacer ton bloc de mémoire et donc de rendre __D_plane et __L_plane invalides?

boogerman
a écrit : J'ai retire le PC et ça marche, mais j'utilise a68k et le link de doorsos, donc je crois pas que ce soit la faute de tigcc (car je ne m'en sers pas)

Le link de DoorsOS est dépassé et bogué!!!
On l'utilisait dans les anciennes versions de TIGCC, mais ce n'est pas pour nous amuser qu'on l'a remplacé par un système de 3 programmes.
Donc poubelle.

Au fait, j'ai voulu m'en servir, mais j'ai pas trouvé quelle est la syntaxe pour linker sur CMD. Lorsque je fais gcc fichier1.o fichier2.o il me dit could not find ld.exe check that it is correctly installed ou un truc du genre.

tigcc fichier1.asm fichier2.asm
(Et pas besoin de linker avec gray.s explicitement, il y a tigcc.a pour ça.)

boogerman a écrit :
Au fait, que se passe-t-il is je fais des HeapAllocHigh après avoir appelé GrayOn. Ça risque pas de déplacer ton bloc de mémoire et donc de rendre __D_plane et __L_plane invalides?

Non, le bloc alloué par GrayOn est verrouillé.

ou makepgrm de pphd qui est

MakePrgm ne supporte pas la compilation séparée (linking de plusieurs fichiers objet) ni les librairies statiques!

Merci Kevin!!! Que c'est beau!

http://natsumi.boogersoft.com/projects/tigb/archive/next-release-hint.png

Le seul prob: quand je désactive les interruptions avec:

init	lea	oldSR(PC),atmp1		;disable interrupts
	move.w	#$0700,d0
	trap #1
	move.w	d0,(atmp1)

(avant d'appeler GrayOn, bien sûr) ça ne marche plus (ça ne montre qu'un seul plan).

Workarounds? (il faut absolument désactiver les interruptions pour éviter l'odieux keyboard buffer)

(ps: vous savez comment ça marche ce media bidule. Je voulais insérer un screenshot dans ce post mais j'ai du me contenter du lien)

boogerman a écrit :
Le seul prob: quand je désactive les interruptions avec:

init	lea	oldSR(PC),atmp1		;disable interrupts
	move.w	#$0700,d0
	trap #1
	move.w	d0,(atmp1)

(avant d'appeler GrayOn, bien sûr) ça ne marche plus (ça ne montre qu'un seul plan).
Workarounds? (il faut absolument désactiver les interruptions pour éviter l'odieux keyboard buffer)

Voilà ce que dit la documentation de OSSetSR dans TIGCC:

However, if you disable interrupts, the grayscale will not work, because the grayscale is also based on Auto-Int 1. To solve this problem, instead of disabling Auto-Int 1, you may redirect it to nothing. See DUMMY_HANDLER from intr.h for more info.

En assembleur, ce qu'il faut faire, c'est:

 move.l $64,oldint1
 lea.l dummyhandler(PC),a0
 move.l a0,$40064
 ;...
 bsr GrayOn

 ;... programme principal ...

 bsr GrayOff
 ;...
 move.l oldint1(PC),$40064
 ;...
 rts

dummyhandler: rte ;attention: rt[b]e[/b], pas rt[b]s[/b]
oldint1: dc.l 0

(ps: vous savez comment ça marche ce media bidule. Je voulais insérer un screenshot dans ce post mais j'ai du me contenter du lien)

Pour les images, il faut utiliser [img], pas [media].

Génial Kevin, et encore merci merci merci pour corriger mes Ânneries

Bon voila l'image:

ah oui en effet c´est ñieux

-

Quand je pense qu'il y a 1ans 1/2 j'avais proposé l'idée de faire un emulateur game boy et qu'apres ya sa qui est apparu dans la faq de TI-Fr :

Pourquoi n'y a-t-il pas d'émulateurs Amiga/Atari/Game-Boy/Mégadrive pour TI ?
L'idée est séduisante et en a fait rêver plus d'un. Malheureusement, à part si vous connaissez des mutants, il est fort peu probable que ce type de programmes soit réalisé un jour. Bien sûr, la TI possède le même processeur que la mégadrive, l'Atari et l'Amiga. Même que le processeur de la TI tourne plus vite que celui de la mégadrive. Mais... presque tout, dans ces consoles, était optimisé pour le jeu, ce qui est très très loin d'être le cas de la TI (quand on voit qu'à la base, elle n'est pas prévue pour afficher des niveaux de gris...). Signalons, par ailleurs, des petits détails, du genre la taille de l'écran, ou bien les coprocesseurs graphiques et mathématiques que ne possède pas la TI... Enfin, la plupart des jeux qui existaient sur ces machines faisaient au moins 500Ko en place mémoire... Bref, rêvez pas.

Alors j'te souhaite bon courage, déja qu'en plus apparement c bien avancé

Vivement une version exploitable

(Ou alors boogerman t un mutant.

Tu fait partit des Xmens ?? )

bref, c'était impossible, lui ne le savait pas et il l'a fait

exactement

Orion_ a écrit :
c klr, que la c bien mieux, c quand que la new version sera en ligne ?
(et plus de user lib , hein )

Ça viendra. Il faut que je remette en marche le debugger qui fait tout peter maintenant. Il appelle userlib::idle_loop qui aparamment a bessoin de l'auto int 1 du TIOS. En plus, toutes les foncions merdiques du TIOS (ie: drawstrxy) écrivent sur main_lcd et non pas sur le LCD actif... Donc il va faloir que le debug comprenne les différents HW pour tout remettre en place à chaque fois.

Eh ouais ouais tous ceux qui dissent qu'ils n'ont rien à foutre du debugger, eh ben sans lui je peux pas corriger les bugs , donc c'est absolument prioritaire...

Et puis ne vous attendez pas à grande chose. Ça fera plus beau mes ça continuera a ramer terriblement

tiens boogerman, tu viens de me donner une id #héhé#

J'verrait bien si sa sera realisable

boogerman
a écrit : Il appelle userlib::idle_loop qui aparamment a bessoin de l'auto int 1 du TIOS.

Si tu utilises les niveaux de gris de TIGCCLIB, tu peux remettre l'ancien auto-int 1 sans désactiver les niveaux de gris en écrivant son adresse en __gray_old_int1_hw1 et en __gray_old_int1_hw2.

En plus, toutes les foncions merdiques du TIOS (ie: drawstrxy) écrivent sur main_lcd et non pas sur le LCD actif...

http://tigcc.ticalc.org/doc/graph.html#PortSet