150

Je pense que je vais effectivement raccourcir le code au plus possible, puis que je rajouterais le reste progressivement, en faisant des tests à chaque fois... mais je ne peux pas le faire tout de suite, vu que j'ai qu'une calto, et pour utiliser le débuggueur de wabbitemu, je veux bien, mais ça marche sur ému...

151

Qu'est-ce que fait _ipoint ? Afficher une pointe sur l'écran ? Il y a d'autres routines disponibles sur ticalc qui le font aussi. Je ne sais pas où est le problème, mais je peux peut-être demander au développeur de WabbitEmu s'il a des idées. Je ne sais non plus s'il aura quelque chose à voir avec les interruptions ?

152

Slt!
Pour _ipoint, c est la romcall qui permet de changer l etat d un pixel (allumer/fermer/inverser/tester)
Les interruptions, si j ai bien compris, sont desactivees par ion, comme je ne les active pas, ca ne vient a priori pas d elles
Oui ca serait sympas que tu demandes au developpeur de wabbitemu s il a une idee ^^
Merci! smile

153

C'est fait:
http://wabbit.codeplex.com/discussions/401338 smile

Et oui, il se peut que ion les désactive, mais certains BCALLs les réactivent (par example, _GetKey) et je ne sais pas quels autres.

154

ok, merci beaucoup smile

155

Il a dit que l'émulation du port mini-jack n'est pas parfait, qu'il y a pas mal de temps qu'il a voulu l'améliorer et qu'il y bosse régulièrement mais que pour le moment il est mieux de tester oncalc, parce que c'est pas complètement fiable. Malheureusement ça ne t'aide pas beaucoup :/ Moi j'ai acheté récemment deux caltos pour tester mes propres projets mais elles n'ont pas de cable TI pour connecter l'une à l'autre (seulement à l'ordinateur), sinon je voudrais t'aider. Dans quelques mois peut-être je pourrai m'en acheter un, mais j'espère que tu n'auras toujours pas ce problème dans quelques mois !

EDIT: Une autre option c'est de demander sur Cemetech:
http://www.cemetech.net/forum/viewforum.php?f=16

Kerm Martian, l'admin de Cemetech, a travaillé beaucoup avec le port mini-jack et il est très probable qu'il peut t'aider.

156

Merci!
J ai cree un sujet comme tu me l as conseille, j espere qu ils pouront m aider ^^ (et de ne pas avoir fait trop de fautes aussi cheeky )
www.cemetech.net/forum/viewtopic.php?p=193579#193579

EDIT:He ben,c est des rapides eux wink
Donc a priori le probleme viendrait de vputs...

157

Tu as pu le tester ? Ca marche ?

158

Bah je sais pas, vu que j'ai qu'une calto et pas de câble tongue
Mais à la rentrée j'ai un pote qui dois me prêter son câble, je pourrais tester, je vous tiens au courant wink
Encore merci pour votre aide ! smile

159

Bonsoir à tous,
J'ai un petit problème:
pour remplacer l'utilisation de _vputs, je voulais utiliser _iline (puisque que j'utilisais vputs juste pour faire un tiret entre les 2 scores)
J'ai donc fais le code suivant (pour l'affichage du score de départ 0-0 en écriture non-inversée):
 ;On affiche les scores
        ld bc,$2B3C
        ld de,$2D3C
        ld h,1
        bcall _iline

	ld hl,$27
	ld (pencol),hl
        xor a
	bcall _setxxop1
	inc a
	bcall _dispop1a

	ld hl,$30
	ld (pencol),hl
        ld a,1
	bcall _dispop1a

Mais je me heurte à un problème: quel que soit l'ordre dans lequel je les affiches, le premierer "0" et le "-" s'effacent l'un l'autre cheeky
J'avais déjà remarqué que ipoint/iline effacent quelques pixels aux alentours, mais je ne savais pas pour disop1a...
Je ne sais pas trop comment contourner ce pb, est-ce que quelqu'un aurait une suggestion?
Merci d'avance smile

160

Le plus simple c'est de commencer par afficher les "0" puis ensuite de dessiner le tiret, non ?

161

Oui mais si je fais ça, quand le tiret y s'affiche, il efface une partie du 0... et là, c'est le 0 qui efface une partie du tiret cheeky

162

Tu places bien ton tiret au moins ? Parce qu'_iline est censé se restreindre aux coordonnées spécifiées confus

Tu peux prendre un screen ?

163

Voilà:
[IMG]http://img40.imageshack.us/img40/8827/screen1b.gif[/IMG]
J'ai modifié le code pour faire d'abord les "0":
	ld hl,$27
	ld (pencol),hl
        xor a
	bcall _setxxop1
	inc a
	bcall _dispop1a

	ld hl,$30
	ld a,1
	ld (pencol),hl
	bcall _dispop1a
	
	bcall _getkey
	
        ld bc,$2B3C
        ld de,$2D3C
        ld h,1
        bcall _iline


et c'est pas la première fois que ça me le fait, je pensais que c'est normal trifus

164

Ça le fait aussi si on change les coordonnées x... hum

Par exemple avec :

	ld bc,$2F3C
	ld de,$3A3C
	bcall _darkline

fou

Tout ces bugs avec les rom calls commencent vraiment à m'en dégouter... Autant se servir de routines fiables : http://wikiti.brandonw.net/index.php?title=Z80_Routines:Graphic:LineDraw

165

Mais ca semble se produire que lorsque on utilise ipoint/iline... pres de disop1a/vputs parce que j utilise ipoint dans mon snake,et ca le fait pas cheeky

166

Pourquoi ne pas faire quelque chose comme:
ld hl,gbuf+(endroit dans gbuf)
ld a,%11100000
or (hl)
ld (hl),a
?
C'est beaucoup plus rapide et plus petit aussi. Ou tu n'affiches pas au gbuf ? Tous les BCALLs sont très lourds et très lents et c'est difficile savoir exactement ce qu'il font avec les registres, etc. à moins que tu ne désassembles le TI-OS pour le savoir wink

EDIT: A propos de ton problème, il se peut que la ligne ne s'affiche pas avec OR mais avec AND, donc s'il y a des pixels dans le même octet ils vont s'effacer.

167

chickendude (./166) :
Tous les BCALLs sont très lourds et très lents

Lent c'est sûr mais lourd, ça ne coûte qu'un "call" (4 octets) pour les 83 et un "rst 28h \ .dw" (3 octets) pour les 83+, non ? Enfin il faut ajouter la taille des "registres paramètres" mais bon, ça reste moins lourd que de devoir ajouter un tas de routine dans son programme pour faire la même chose.

Perso je les utilise lorsque j'ai pas besoin que le programme aille trop vite, au final ça me gagne quelques octets. Mais bon de toute façons à part quelques-unes, elles sont loin d'être toutes utiles (l'une des rares que j'utilise assez souvent c'est _ldhlind).

168

Ah bon tu as raison :P

Quant au _ldhlind, normalement pour faire ça on n'utilise que 4 octets:
ld a,(hl)
inc hl
ld h,(hl)
ld l,a
Tu peux même faire un macro! Ou si tu veux gagner cet octet, tu peux fair une routine dans ton programme pour le faire wink Pour faire certaines choses, comme jouer avec la VAT, créer un programme/variable, etc. je crois qu'ils sont indispensables, mais normalement je préfère écrire mes propres routines smile

J'utilisais le fichier source de ce programme (parce que j'avais déjà fait un script pour l'assembler/envoyer à l'émulateur):
fH6H
...pour déboguer le code de quelqu'un mais quand je voulais l'assembler je me suis rendu compte de que j'avais même pas défini bcall dans mon programme :P

169

Ouais mais si on en fait une routine il faut compter l'octet du "ret" en plus. Finalement il n'y a pas tellement de rom calls qui vaillent le coup d'être "recodés", sauf en cas de bug comme là avec _iline et _darkline...

Enfin je pense que l'utilisation des rom calls est inversement proportionnelle à l'expérience du programmeur, et vu ton niveau c'est normal que tu puisses t'en passer tongue

Moi c'est pas encore ça grin

170

Oui et comme tu as dit, ça dépend de tes nécessités. Pour moi je crois qu'il vaut la peine presque toujours parce que l'on gagne beaucoup de vitesse pour très peux d'espace. D'autres choses comme une routine de texte par exemple, les bénéfices ne sont pas aussi claires (pas mal d'espace), pendant que d'autres fois tu n'auras pas de choix, les routines de TI simplement ne te serviront pas (si tu veux afficher à un autre buffer, etc.). Et mon niveau n'est pas trop bon, c'est sûrement pour ça qu'il faut que j'écrive mes propres routines : parce que le reste de mon programme est trop lent wink J'aime aussi pouvoir dire que l'on peut utiliser tout ce que j'ai écrit sans limitations, si j'utilise du code de TI ou d'autres sources il n'est pas totalement sûr que je puisse dire que tout le code est "libre" smile (C'est drôle, non ? que l'on voudrait garder pour soi-même du code pour une calculatrice graphique qui ne va pas lui servir de rien ? :P)

171

Oui je ne vois pas trop l'intérêt de ne pas partager le code source de ses programmes (de manière générale, sauf lorsqu'il s'agit de question de sécurité).

172

Je suis en train de désespérer: j'ai enlevé _vputs de mon prgm et... ça ne marche toujours pas, il y a toujours le même bogue mur
Pourtant je désactive les interruptions avant de passer en 2 joueurs... peut être que _ipoint les réactive?
Par contre, la version 1 joueur marche impec' top

173

Essai de voir avec un débogueur, mais ça m'étonnerai :/

174

Si!
Je tombe sur un ei à l'adresse $4230 en suivant un call _ipoint cheeky
Je vais donc approfondir le port $10 et $11, et créer mes propres routines d'affichage de point grin

175

Mmh ok je vois pas trop l'intérêt d'activer les interruptions pour afficher un pauvre point, je me demande bien comment TI a codé ça... cheeky

176

Bah en fait, les interruptions sont désactivés au début, et remise à la fin (je pense que c'est parce que ipoint utilise les registres miroirs (je sais plus si on dit bien comme ça?), et du coup, une interruption pourrait tout bidouiller tongue

177

Mouais enfaite c'est pour ne pas détruire de registres, mais ils auraient quand même pu utiliser la pile au lieu des registres "shadow".

178

Tu pourrais aussi tester avec un simple "di" après chaque appel à _IPoint, mais je ne sais pas comment fonctionne la connexion entre les deux caltos :/ Beaucoup de BCALLs le font, ajourd'hui même j'ai eu un problème avec le BCALL _Arc_Unarc qui activait les interruptions et me causait des ennuis. C'est peut-être comme tu dis, TI désactive les interruptions pour faire quelque chose (travailler avec les registres shadow) puis les reactive à la fin du BCALL. Et je crois qu'en français on dit "les registres cachés" ou "secondaires", ou, en anglais, on dit les registres "shadow" wink

A propos, je crois qu'avec WabbitEmu, TilEm2 et même PindurTI tu peux voir le status des interruptions dans le debuggeur, il ne faut pas chercher un di/ei dans les BCALLs wink