Port mini-jack - Page 6

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 ?

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!

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

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.

ok, merci beaucoup

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.

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 )
www.cemetech.net/forum/viewtopic.php?p=193579#193579

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

Tu as pu le tester ? Ca marche ?

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

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
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

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

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

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

Tu peux prendre un screen ?

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

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

Par exemple avec :

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

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

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

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

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.

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).

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 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

J'utilisais le fichier source de ce programme (parce que j'avais déjà fait un script pour l'assembler/envoyer à l'émulateur):

...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

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

Moi c'est pas encore ça

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 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" (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)

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é).

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
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'

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

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

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...

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

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".

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"

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