Port mini-jack - Page 5

Ah oui, le plus simple alors c'est de faire :

_bell_recvFirst_skip: 
	pop bc
	ld a,b
	ret

On se fout bien de la valeur de l'accumulateur si ça a échoué ?

Oui, complétement
Merci beaucoup! Je teste ça sur calto dès que possible, mais sur émulateur ça marche (même si apparemment, ça veut rien dire ^^)

Y'a plus de crash/problème de connexion du tout ?

Vu que je prévois peut être d'utiliser du link dans un de mes projets ce serait rassurant

Vu que je n'ai pas le câble, je n'ai pas pu tester pour l'instant. J'envoie mon code à un pote, qui dois le tester (il a un câble et ma calto), donc normalement, je devrais avoir une réponse ce week-end... je croise les doigts

Bon, à priori, j'ai encore une rom call qui détraque le port mini-jack...
Ça bloque à chaque fois qu'on appuye sur une flèche par exemple (même si des fois ça déconne sans qu'on fasse quoi que ce soit...), donc du coup je suppose que ça fait que les 2 caltos arrivent pas en même temps à la routine de connexion, et celle en retard serait donc en train d'utiliser un routine qui fait bugguer...
Je cherche, je vous préviens si je trouve une piste (même si je pense que ça devra attendre confirmation à la rentrée (je n'ai ni câble, ni 2 caltos...)

PS: Bonnes vacances!

EDIT: Vous auriez une idée de ce que veux dire "The SDK is wrong."?
J'ai trouvé ça dans la doc' sur la rom call Vputs sur wikiti...
Merci d'avance!

Désolé pour le double post, mais j'ai une nouvelle info de Timendus, et je ne comprends pas tout ce qu'il m'a dit:

It's not necessarily getkey that messes with the link port, but -- if I remember correctly -- the Ti-OS silent link transfer code. This is the code that enables you to push programs to the calculator from your PC when you're in the Home screen (not in receive mode). The code is triggered by an interrupt controller and by getkey. Once it gets triggered it starts communicating with the other calculator instead of letting Bell do that.

J'ai compris qu'il dit que c'est pas forcément la faute de getkey, mais aussi du " Ti-OS silent link transfer code": il explique après que c'est le code qui permet les transferts ordi-ti, qui se met en place après une interruption ou un getkey, d'où le bug de bell, mais je comprends pas bien pourquoi... j'ai enlevé les getkey donc ça devrait plus le faire (c'est ce passage que je pense n'avoir pas bien compris)
Et qu'est ce qu'une interruption exactement (je n'arrive pas à trouver de réponse satisfaisante...)
Merci d'avance!

Une interruption c'est un code qui est exécuté de manière cyclique durant l’exécution "normale" du code de la TI, cf http://www.mworld.fr/html/projects/calc/ti-82/tutoriel/progasm/guide/lesson20.html, et pour la théorie : http://quasar.cpcscene.com/doku.php?id=iassem:interruptions.

Et comme le "silent link transfer" est apparemment une interruption qui se charge de gérer la réception de fichiers sur la TI lorsque la TI n'est pas en mode réception (quand on est sur l'écran "home" par exemple), si c'est activé alors c'est normal que ça bug, mais il dit qu'il n'y a que deux façons que ça se fasse : avec _getkey (y'a d'autres rom calls moins communs selon le SDK, mais de toute façons tu ne les utilises pas) ou en activant les interruptions (instruction ei).

Sachant que Ion les désactive, sauf si ton programme ou bell les réactive y'a pas de raison que ce soit ça...

Enfin de quelle façons tu fais les pauses déjà ? Avec ei+halt+djnz+di, non ? Si c'est le cas je me demande si ça ne suffit pas à tout foutre en l'air (même si les interruptions sont désactivées à la fin de la pause)...

edit : sauf si ton code source à énormément changé, non c'est pas ça... Tu peux le poster à nouveau ?

Vous auriez une idée de ce que veux dire "The SDK is wrong."?

Ça veut dire que le Software Development Kit de TI se goure sur certains trucs (en l’occurrence la destruction de registres à la sortie de rom calls il me semble).

Merci pour les lien

J'ai cherché dans mon prgm et dans les routines de bell, et je ne met jamais ei.
Voici mon code

Bon j'ai corrigé quelques fautes de bcall/bjump/jp/call qui faisaient bugger la version 83+, et ton problème viens apparemment de ta gestion des événements... D'ailleurs je ne vois pas trop où tu fais le swap des événements dans ton code ?

Autrement ça tu vas faire en sorte qu'il n'y ait qu'une des deux TI qui choisisse le niveau ou pas (genre un choix entre serveur/client) ? Parce que là ça fait un peu bizarre, non ?

ZSNAKE.zip

Je fais l'échange des évènements ici (tu dis que ça vient des évènements, mais ou plus précisément?) :

GET_EVENT:
        ;On échange les évènements
	pop hl			
	ld (GET_EVENT_SAV_HL),hl
	ld hl,my_x
	ld de,his_x
	ld b,8
	call bell_swapBlock
	jp nz,CONEXION_LOST

Je ne comprends pas... à priori, tu as remplacé tous les "bjump xxx" par des "bcall xxx /ret"... ça reviens au même non?

Pour les niveaux, oui, je comptais faire un truc du genre (mais je préfère d'abord me concentrer sur le bug). Il y a encore d'autres trucs à améliorer, je m'y met dès que ça marche.
Merci pour ton aide!

Pas exactement (pas sur 83+ en tout cas), cf ./115

Enfaite le seul bug qui reste c'est le fait que ça termine la partie sans raison, non ? Parce que si tu commentes les lignes 859 et 860 (" bit 1,a\ jp nz,EXIT_GAME"), tout marche nickel (hormis si on sort de l'écran).

J'ai pas trop le temps de vérifier, mais tu es toujours sûr de ce que tu mets dans his_event ?

Donc en fait, pour les bcall+ret et bjump c est juste le nombre doctets qui change? Parce que si c est ca,je prefere en prendre moins pour la version 83 que pour celle 83+, qui a plus de memoire ...

En fait le bug ne se situe pas exactement là, mais au niveau de la routine de bell pour le swap: on ne passe pas par l affichage du score, mais par un "connexion perdue". Ca ne vient pas d une caltos trop en avance par rapport a l autre, j ai modifie quelques trucs dans bell pour tester, pour qu'on quitte la routine apres l appui sur une touche au lieu d un certain temps (tres court), et ça semble marcher,mais au bout d un moment tout s arrete, ce qui veut dire que la calto un peu en retard a execute une commande qui a detraque le port 0, y a pas d autre explication...

Le probleme ne vient donc pas de ce que je met dans hi-event

mathieu41 (./132) :
Donc en fait, pour les bcall+ret et bjump c est juste le nombre doctets qui change? Parce que si c est ca,je prefere en prendre moins pour la version 83 que pour celle 83+, qui a plus de memoire ...

Pour la 83 oui, pour la 83+ y'a une histoire de sauts d'adresses qui font qu'en gros c'est douteux d'utiliser bjump en remplacement de bcall+ret.

mathieu41 (./132) :
on ne passe pas par l affichage du score, mais par un "connexion perdue".

Dans mes tests avec wabbitemu (83+), si :/

C'est vraiment à n'y rien comprendre

À la limite faudrait tenter sans _getcsc (même si le SDK indique que ça n'interfère pas avec le silent link truc...), parce qu'autrement je ne vois pas...

Et ca stope direct, ou ca joue un peu? parce que si ca joue un peu c pas une histoire de getcsc vu que je l utilise pas dans le jeu en lui meme
Pour moi, sur wabbitemu(83) et sur des ti82stats.fr, ca bogue comme je tai dis,c est bizare que ca soit different pour les 83+

Oui on peut jouer un peu (même récupérer une pomme), mais au bout d'un moment ça affiche direct le score puis ça quitte...

En enlevant ce que je t'ai dit ça semble ne pas bugger plus que ça...

Autrement faudrait essayer de virer tous les menus, ne garder que le moteur du jeu en lui même (que lorsqu'on lance le programme ça en soit à la connexion), au moins si ça bug toujours on saura qu'aucune rom call des menus n'a activé le "silent link protocole"... Et avoir moins de code à débugger ça peut toujours aider.

En fait, si une des rom call menu auraient activé le silent link protocole, on ne pourrait pas du tout jouer, ça boguerait dès le début...

Heu... Je viens de tester le 8xp que tu m'as passé et... tout marche impec sur la 83+ ... tu es vraiment sûr qu'un des serpents n'est pas mort? (ou que tu n'as pas tenté de rebrousser chemin?)

C'est vraiment à n'y rien comprendre...

Il me semble que non, mais tout seul c'est dur de ne pas en faire crever un au bout de 5sec... En plus lorsque la partie se termine ça affiche le score, puis le "splash screen" (titre), puis ça quitte mais ensuite tu as pas mal de caractères étranges à l'écran et parfois même un RAM CLEAR (mais lorsqu'il y en a pas le jeu accepte de se relancer, donc si c'est une corruption de données, ça ne le fait pas tout le temps...).

Tiens je viens de tester avec la dernière version de wabbitemu (sortie ce matin !), et en appuyant sur la direction inverse du snake (gauche alors qu'il allait à droite), ça a terminé la partie puis quitté et seulement l'une des deux TI à "crashée"...

Hum..... Chez moi, tout marche impec' sur émulateur :

(Je me rend compte que ma capture n'est pas super, c'est parce que j'ai modifié la vitesse de wabbitemu à 25% lorsque je jouais. Mais on voit bien qu'il n'y a pas de bug...

EDIT: Il n'y a pas de "x" normalement... Comment ça se fait qu'ils apparaissent sur tes compilations?

REEDIT: En fait non, on dirait qu'il y a des bug... mais c'est à cause de ma capture (il y en avait pas quand j'ai joué), normalement la 1ère fois je fais rebrousser chemin à un des serpents, le score s'affiche pour les 2, puis je relance, au bout d'un moment j'en balance un sur un mur, le score s'affiche normalement, et là j'arrête la capture...

J'en sais rien, j'ai pas touché à ça

Tu as testé sur 83 (avec mes binaires) ?

Oui, j'ai testé sur une 83, et ça met les "x", alors qu'avec mes 83p et 8xp, ça le faisait pas
EDIT: Il y a eut un pb avec la chaine: je l'ai modifiée en copiant celle de mon z80, et ça l'affiche normalement. Celle de ton fichier était plus petite

Ah c'est parce que tu avais mis des tabulations au lieu d'espaces :

S_RECHERCHE:
	.db "Recherche    d",$27,"un adversaire   patientez...",0

Non j'avais bien mis des espaces...
Bon ben c pas grave, tant pis

Tu compilais avec quoi ? Tasm ? P't'être qu'il traduit les tabulations comme des espaces, mais pas Spasm... Puis certains éditeurs de texte/IDE asm rendent mal les tabulations (donc on peut facilement les confondre avec des espaces).

Enfin tant mieux si ça bug moins, faudrait juste être sûr que ça marche oncalc.

Bah justement,y a rien change d inportant depuis mon essai vendredi,et ca faisait quitter la routine de bell... (oncalc pas sur l emulateur)

J utilise pourtant Spasm depuis que tu m as passe une version qui marche

J'ai quand même changé quelques trucs en ./129

Oui, mais pour les 83+ surtout, et je ne peux tester que sur des 82stats.fr...
Ca buguait au niveau de la routine de bell, donc comme il n'y a rien de changé à ce niveau là...
J'ai envoyé un message à Timendus pour savoir si vputs/ipoint/setxxop1/dispop1a peut faire buguer la connexion, et j'attends sa réponse...
Au pire, je peux toujours recoder ipoint (avec les ports $10/$11), me passer de setxxop1/dispop1a, mais difficilement de vputs (ou sinon en gardant setxxop1 et dispop1a, et pas vputs)
Donc je préfère attendre de voir si il sait si une des 4 rom call fait tout buguer avant de me lancer...

Nan mais déjà tu peux tester en les virant (bon ce sera plus difficile pour _ipoint mais bon ça m'étonnerais que ce soit ça et sinon y'a des routines), tu verras ce que ça donne...

T'es sûr et certains que ça viens de bell ?

Oui, car voici ce que j'ai fait:
J'ai modifié les routines de bell (mais ça ne marchait déjà pas) pour que le prgm quitte non pas après $FFFF passages dans les boucles, mais après l'appui sur 2nde. Là, je me suis aperçu que le jeu, quand il bugue, ne quitte pas direct: il faut appuyer sur 2nde, et ça va à connexion perdue.
En plus, si ça serait autre chose, ça buguerait aussi sur ému, non? (vu qu'on a constaté que getkey fait buguer la connexion oncalc, et pas wabbitemu)

J'ai quand même eut quelques bugs sur emu, hein.

Je te dis, le plus simple c'est de raccourcir ton code et de ne garder que le moteur du jeu (le strict minimum), si ça bug plus alors c'est que ça viens d'autre chose (ton menu, un rom call...), sinon c'est que ça viens de ton jeu. Ce serais peut être même plus simple en utilisant le débuggueur de wabbitemu.

Ce qui m'étonne c'est que le programme de test que j'avais fait en ./26 marchait parfaitement (pas de bugs venant de bell).

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