PolySnd Bêtas testeurs - Page 4

La convention d'appel standard de la plateforme veut que tu n'as le droit de détruire que d0-d2/a0-a1. Tu auras des ennuis avec le C si tu détruis des registres parmi d3-d7/a2-a6.

Donc je suis cette conversion, reste à savoir pourquoi j'ai ce bug bizarre.

Es-tu sûr que tes données de son sont à une addresse paire? Peut-être un bogue du linker (obj2ti, qui heureusement va bientôt être remplacé)?

Mes données sont codé sur 8 bits, donc ça ne semble pas un problème ici, surtout qu'avant ça fonctionné bien sauf sur TI89 ou il y avait ce genre de plantage.

Encore un bug bizarre cette fois que sur TI89 et testé que sous Virtual TI.
Lors de l'execution d'un programme en C version statique, (ce programme n'affiche rien, il ne joue que du son), il semble bien fonctionner, je le quitte sans problèmes... mais lorsque je vais dans le menu Var-Link, le menu ce bloc avec une liste vierge et busy en bas. Ce bug n'apparaît pas sur ma TI92+ mais apparaît sur la version TI92+ de Virtual TI.

Je vais passer au peigne fin le code de ma librairie car c'est bizarre mais avant ça je veut ça ce qui peut produire ce genre d'erreurs?

ça pourrait peut-être venir d'une variable globale qui serait détruite par PolySnd ou alors de la VAT qui serait corrompue. (Mais comment cela peut ce produire, je n'en ai aucune idée).

VTI émule une HW1, donc c'est peut-être le même bogue que sur HW1.

Donc j'ai encore effectué des tests, j'ai écarté l'interruption de PolySnd (la plus gros partie), toujours les même bug voir pire pour un autre bug.
En executant le prog minimal sans l'interruption de PolySnd, normaklement celui-ci doit ce terminer sans problème et là j'ai un message d'erreur memory, puis le curseur du TIOS bouche tout seul, ce bloque dans la barre et les menus déconne à fond, jusqu'à ce que Preos remet tout en ordre. Je fais un tour dans la mémoire et aucun octet de perdus.
Par contre sur ma TI c'est autre chose, juste un crash intecepted sans problèmes.

ça pourrait peut-être venir d'une variable globale qui serait détruite par PolySnd ou alors de la VAT qui serait corrompue. (Mais comment cela peut ce produire, je n'en ai aucune idée).

Je vois pas comment je pourrais corrompte la VAT dans un programme en statique alors qu'en dynmaique c'est pas le cas, en plus dès que je relance le programme en staique il fonctionne toujours correctement.

VTI émule une HW1, donc c'est peut-être le même bogue que sur HW1.

J'ai bien peur que ce bug que je n'ai jamais vu apparaisse, ça me rassure mais il est quand même assez grave sur HW1, vu ce que je vois sur Virtual TI.
En ce moment je cherche dans quelle fonction il eput ce trouver, déjà il ne ce situe pas dans l'interruption de PolySnd et ça me rassure.

Et bah, je sens que je vais passer énormément de temps à trouver ce bug.

Voilà ce que j'obtient en faisant des tests:

	include		"doorsos.h"	
	include		"polysnd2.h"				
	xdef		_ti89
	xdef		_ti92plus
	xdef		_main
	xdef		_comment
	
_main: 
 	jsr	polysnd2::EnableSound
	jsr	polysnd2::InstallSound
 	jsr	polysnd2::PlayMode	
   	jsr	polysnd2::SetTempo_voice1
 	jsr	polysnd2::SetTempo_voice2	
 	jsr	polysnd2::PlaySound_voice1
  	jsr	polysnd2::PlaySound_voice2
 	jsr	polysnd2::SetState
 	jsr	polysnd2::UninstallSound
	jsr	polysnd2::DisableSound
	rts

_comment dc.b	"Duke nukem 3D intro",0	

channel1:
	dc.b	255
channel2:
	dc.b	255
	end

J'ai rompus toutes les fonctions de la librairie, elles ne contiennent que des rts.

La calculatrice ce plante, par contre je constate que dès que je retire une fonction dans ce code, le programme ne plante pas ou encore je retire _comment.

D'après ta description, ça me semble être un bogue:
* soit de obj2ti (le linker de TIGCC 0.94),
* soit de PreOs.

Il faudrait inspectionner les fichiers pour voir s'ils correspondent aux spécifications. S'ils correspondent, c'est un bogue de PreOs, sinon c'est un bogue du linker.

inspecter, non ?

D'après ta description, ça me semble être un bogue:
* soit de obj2ti (le linker de TIGCC 0.94),
* soit de PreOs.
Il faudrait inspectionner les fichiers pour voir s'ils correspondent aux spécifications. S'ils correspondent, c'est un bogue de PreOs, sinon c'est un bogue du linker.

Ca m'arrange pas.

Je vais voir demain ce que je peux faire.

Le crash intercepted n'est en faite qu'un Illegal Instruction.

Illegal sigbiefie quoi plus précisément? Que le processeur ne reconnaît pas une suite d'octet identifié comme instruction, ce problème peut survenir lorsque le processeur execute des instructiuons sur une adresse impaire?
Au niveau du Kernel et du programme en mémoire comment ce passe le linkage entre la librairie et le programme?
Le fait de compiler les 2 modéles en même temps peut être source de problèmes????
_comment doit ce situe ou dans un programme?

Je vais réinstaller TIGCC car avec la version 4.38 je n'ai pas ce plantage sur ma TI92+ mais sur Virtual TI il existe.
TIGCC 0.95 subira quoi comme modifications au niveau de l'ASM? Et où je peux me procurer une version non finit de TIGCC 0.95?

Illegal sigbiefie quoi plus précisément? Que le processeur ne reconnaît pas une suite d'octet identifié comme instruction, ce problème peut survenir lorsque le processeur execute des instructiuons sur une adresse impaire?

Illegal instruction est toujours généré par l'instruction ASM illegal et peut-être aussi par des instructions non supportées par le processeur. Une adresse impaire génèrerait Address Error

geogeo
: Illegal sigbiefie quoi plus précisément? Que le processeur ne reconnaît pas une suite d'octet identifié comme instruction,

Oui.

ce problème peut survenir lorsque le processeur execute des instructiuons sur une adresse impaire?

Non. (Ça donnerait un "Address Error".)

Au niveau du Kernel et du programme en mémoire comment ce passe le linkage entre la librairie et le programme?

Le kernel s'occupe du relogement. Si les tables de relogement sont corrompues (à cause d'un bogue du linker par exemple), il peut arriver que le kernel modifie du code en croyant que ce sont des adresses et que ça donne des instructions illégales.

Le fait de compiler les 2 modéles en même temps peut être source de problèmes????

Non.

_comment doit ce situe ou dans un programme?

N'importe où. Ce n'est pas le problème.

TIGCC 0.95 subira quoi comme modifications au niveau de l'ASM?

Nouveau linker, donc au lieu de 3 étapes de linking pour A68k (objcopy, ld, obj2ti), on en a une seule. Et des bogues en moins, j'espère.

Et où je peux me procurer une version non finit de TIGCC 0.95?

Tu peux demander à Sebastian. Mais je ne pense pas que ça vaille le coup, la bêta 1 est pratiquement prête. (Je pense qu'elle sortira en moins d'une semaine.)

Merci pour toutes ses explications, je vais effectuer un débugage et repérer l'instruction qui pose problème.

J'ai effectué le debugage et c'est pas beau mon plantage, ça vient pas de moi.

0749C8> muls.w Illegal,d3
0749CA>>cmpa.l Illegal,a7 encore plus
074CC>1111
074CE>1111
074D0>1111
074D2>1111
074D4>1111
074D6>1111
074D8>1111
074DA>1111
074DC>1111
074DE>1111
...

En parcourant je retrouve souvent des Illegal.

Pensez-vous que si la taille de la librairie est paire, je n'ai pas ce problème?

Avec quoi tu as débogué ? je n'ai jamais vu ce genre d'instructions avec VTI...

Avec DB92 la dernière version sous Virtual TI ROM 2.08.

Tu sais que VTI a un debogueur intégré ?
EDIT: au passage, 749C8 c'est pas dans le ghost space de la RAM par hasard ? Est-ce que c'est normal ?

Tu sais que VTI a un debogueur intégré ?

Je le sais mais j'arrive pas à intercepted le problème avec VTI, je chosit Duke3D comme programme breakpoint puis je le lance et le débugeur ne s'affiche pas, ça me fait toujours ça quand j'execute un programme utilsant une librairie, mais avec mes autres programmes j'arrive à déboguer.

EDIT: au passage, 749C8 c'est pas dans le ghost space de la RAM par hasard ? Est-ce que c'est normal ?

Non, le Ghost Space c'est 0x400+Ton adresse, j'utilkise que le Ghost Space 0x40074.
Je vasi voir en dtéails opu ce trouve mes instructions mais je suis persuadé que le programme ne passe pas par UninsstallSound et encore moins par DisableSound avant plantage.

Ces adresses sont bien dans l'espace fantôme, mais c'est normal. En revanche, il est assez clair d'après le dump que tu es en train d'exécuter des données. Le relogement effectué par le kernel est incorrect.
Essaye avec un autre kernel (Universal OS par exemple) pour voir si c'est PreOs qui bogue. Si ça plante aussi avec Universal OS, alors c'est probablement un bogue du linker.

Franchement, la solution la plus simple à ton problème est de linker statiquement.

Euh c'est ce que j'ai fait, j'ai essayé avec Universal OS et même problème.

Hmmm... C'est presque certainement un bogue du linker. Attends le nouveau, ce problème devrait se règler tout seul.

Pourquoi c'est toujours moi qui trouve ce genre de bugs?

Parce que tu es un des seuls à encore utiliser le mode kernel. Peu de gens l'utilisent, donc peu de gens le testent, donc ça bogue dans tous les sens. C'est tout à fait normal. Programme en _nostub et tu auras beaucoup moins de problèmes de ce genre.

Tu sais c'est à cause d'avoir programmé en ASM avec Fargo sur TI92 que j'utilisais le kernel mais maintenant c'est autre chose.

En attendant d'avoir TIGCC 0.95 (j'espère dans pas longtemps. ), un petit sondage (et pas de débât Kernel-Nostub. )
[sondage=13790]

Essayez de réfléchir avant de voter et surtout si s'est OUI, détailliez votre pensée.

Oui, car la librairie statique est utilisable par tout le monde (en kernel comme en _nostub), donc tu as 2 fois moins de travail de maintenance tout en visant le même groupe d'utilisateurs.

OK.
Juste un point à éclaircir (je n'abandonnerais pas la source de PolySnd en version dynamique et je la diffuserais toujours, car personnelement c'est vraiment plus facile pour programmer en ayant tout le code de la librairie au lieu de bouts de codes dans des fichiers.)

Les fichiers .tpr, tu connais?

Non.

Euh j'utilise polysnd2.tpr en statique aussi ça me déroule au totale 54 fichiers.