Corruption de mémoire bizarre, GPU vs DSP - Page 2

Pour l'optimisation j'ai étudié un peu la question et finalement... On ne gagne pas grand chose même en essayant d'entrelacer le code ou de faire super attention.

Le problème c'est que le nombre d'accès aux registres n'est pas correctement proportionné par rapport à la taille du pipeline.
Avec "seulement" un double port et 1 seule écriture, on arrive facilement à saturation avec un pipeilne à 3 stages

à priori la bonne valeur ça serait un triple port avec double écriture aux registres

On peut optimiser un peu en entrelaçant le code mais c'est vrai que de tous façon les proc de la Jaguar ont leurs limites.

Bon j'ai pas vraiment optimisé, au contraire j'ai éliminé la parallélisation GPU/DSP mais c"est le seul moyen que j'ai trouvé pour éviter le bug de corruption.

J'ai vu dans le code généré qu'il y avait des "clr.l" vers la zone mémoire $Fxxxxx.
je n'ai pas regardé plus en détail, mais je me demande si dans certains cas on ne se retrouve pas dans le bug des instructions "clr.l" et "move.l <ea>, -(an)" provoqué par un pb de partage de bus qui ferait que du coup le DSP/GPU obtiennent une valeur erronée et fait tout crasher.

j'aurai voulu regardé avec l'analyseur logique mais y a que ma jagBJL qui est prévu pour cette manip
Je réessayerai de reproduire le problème dessus un de ces jours car ça m'intrigue quand même ce bug.

Merci d'avoir jeté un oeil sur le code généré.
Effectivement j'ai fait pas mal de clr.l en RAM dans le code de ma lib, fou que je suis. Bon je les ai remplacés par des move.l #0. Cependant c'était en RAM, je n'en ai pas vu vers la zone $Fxxxxx.
J'ai aussi vérifié le code généré à partir du C: pas de clr.l en RAM, ni vers le hard de la Jag.
Bizarre...

Je suis curieux à propos de ton analyseur logique. Qu'est-ce que tu peux faire avec? Je m'y connais pas trop en électronique.

Sur ma JagBJL j'ai soudé des connecteurs qui permet de brancher un analyseur logique sur quasiment tout le bus de la jag :



Ca permet d'avoir ce genre d'infos:



J'ai utilisé cette possibilité pour :
- Optimisation extrême => profilage accès mémoire (utilisé pour FACTS)
- Analyse des accès mémoire Blitter/OP pour comprendre certains fonctionnement de la Jag
- Débuggage divers via détection d'accès mémoire par certains CPU et voir le comportement qu'il y a autour (typiquement pour comprendre pourquoi certains jeux fonctionnaient sur le vrai hardware et pas sur le JagFPGA).

Pour le clr.l, je l'ai vu par exemple sur le _timer8KHz.
Peut-être qu'il n'y avait que celui là et que tu l'as supprimé dans une version plus récente.

OK je vois pour l'analyseur logique. C'est classe!
Pour le clr.l j'ai compris. C'est dans le code C. En fait quand je fais timer8KHz = 0; le compilateur C génère bien un move.l #0,_timer8KHz
MAIS l'assembleur a l'option -opt-clr dans son fichier de config qui change les move #0,<ea> en clr <ea>
J'ai retiré cette option diabolique et j'ai même mis -no-opt pour virer toutes les optim foireuses de l'assembleur.

DrTypoFr (./37) :
C'est dans le code C. En fait quand je fais timer8KHz = 0; le compilateur C génère bien un move.l #0,_timer8KHz
MAIS l'assembleur a l'option -opt-clr dans son fichier de config qui change les move #0,<ea> en clr <ea>
J'ai retiré cette option diabolique et j'ai même mis -no-opt pour virer toutes les optim foireuses de l'assembleur.

Est-ce que tu pourrais en dire plus sur le compilateur que tu utilises? Son nom, version, etc.

dilinger (./38) :
Est-ce que tu pourrais en dire plus sur le compilateur que tu utilises? Son nom, version, etc.

J'utilise vbcc, un cross-compilateur disponible sous de multiples plate-formes dont Windows. J'ai récupéré la dernière version en date, la v0.9h.
Le site web est: http://www.compilers.de/vbcc.html
Y'a aussi un assembleur, vasm, et un linker, vlink mais moi j'utilise rmac et rln pour assembler mon code 68000/Jaguar RISC et linker.

En fait vasm est indirectement utilisé dans mon cas car vbcc génère un listing assembleur qui est ensuite assemblé par vasm. C'est lui qui changeait les move.l #0 en clr.l
Bon, j'aurais dû inspecter le vc.cfg où l'option d'optimisation -opt-clr était définie.

Ceci dit le clr.l n'est pas la cause du bug de corruption mémoire que j'observe. Il se produit quand y'a le DSP + interruption DSP + GPU en parallèle.

DrTypoFr (./39) :
J'utilise vbcc, un cross-compilateur disponible sous de multiples plate-formes dont Windows. J'ai récupéré la dernière version en date, la v0.9h.
Le site web est: http://www.compilers.de/vbcc.html
Y'a aussi un assembleur, vasm, et un linker, vlink mais moi j'utilise rmac et rln pour assembler mon code 68000/Jaguar RISC et linker.

Merci.
Je connais ce compilateur, en ce moment, je suis sur gcc + vasm + vlink. Je vais essayer de tâter vbcc.

SCPCD (./18) :
En testant sur une Jag Européenne via une Jagtopus, ça crash effectivement...
Par contre j'ai aucun moyen de debugg sur celle là, va falloir que je trouve un moyen de reproduire sur ma jag BJL du coup

Au fait quand ça a crashé chez toi, c'était dès le lancement ou quelques minutes après?
Parce que si c'était dès le lancement c'est probablement un autre bug. J'oubliais d'arrêter les interruptions à l'init et je crois que ça pouvait faire merder parfois au départ.

Je dis ça parce que j'avais une Jaguar en rab, celle que j'avais acheté à l'origine en 1994. En la re-testant en 2011 elle m'a fait des écrans rouges sur les jeux donc je ne l'ai plus utilisée et j'ai acheté une autre Jaguar.
Donc j'ai ressorti ma Jaguar de 1994 en me disant que finalement c'était peut-être juste le connecteur qui était un peu lâche et que la Skunkboard passerait.
Ben c'est le cas, elle marche avec la Skunkboard et là j'ai manifestement pas de corruption mémoire.

!call DrTypoFr
J'ai testé avec mes 2 jag modèle K en 50hz.
Je t'ai répondu sur AA :

@RadiATIonDDR: ok j'ai vu. Donc sur une de tes jag c'est OK et sur l'autre y'a des problèmes: y'a de la détérioration sur les sons des tirs et un bruit à l'interruption d'une mission, mais la musique est normale.
Là je suis perplexe. Si c'est le bug de corruption mémoire, ce serait bizarre que ça impacte un petit sample comme le tir mais pas un gros sample comme la musique. Serait-ce un AUTRE bug???

DrTypoFr (./41) :
Au fait quand ça a crashé chez toi, c'était dès le lancement ou quelques minutes après?
Parce que si c'était dès le lancement c'est probablement un autre bug. J'oubliais d'arrêter les interruptions à l'init et je crois que ça pouvait faire merder parfois au départ.

Ça crash comme tu le décrivais : au bout de quelques minutes le sons merdouille (~2min) puis crash total vers ~5min.

SCPCD (./44) :
Ça crash comme tu le décrivais : au bout de quelques minutes le sons merdouille (~2min) puis crash total vers ~5min.

OK t'as bien la corruption mémoire sur ta Jag européenne.
Carl Forhan a aussi le problème sur sa jag américaine modèle M.

Bon pour l'instant, avec les infos collectées ici et sur AtariAge, ça a l'air de se produire sur 1/3 des Jaguar.

DrTypoFr (./43) :
@RadiATIonDDR: ok j'ai vu. Donc sur une de tes jag c'est OK et sur l'autre y'a des problèmes: y'a de la détérioration sur les sons des tirs et un bruit à l'interruption d'une mission, mais la musique est normale.
Là je suis perplexe. Si c'est le bug de corruption mémoire, ce serait bizarre que ça impacte un petit sample comme le tir mais pas un gros sample comme la musique. Serait-ce un AUTRE bug???

Celle qui présente le bug evoqué est la jaguar réparée suite propriétaire précédent qui avait du se tromper de polarité. Je ne sais pas si cela peut expliquer quelque-chose... Faut aussi que je vérifie si je ne l avait pas passée en 60hz... Il y aurait moyen de le vérifier sans la démonter ? Un test avec une rom ?

Tu veux vérifier si ta Jaguar est en 60Hz? Je peux modifier mon programme pour qu'il affiche l'intervalle de temps entre 2 VBL en se basant sur le timer 16,6KHz.

Je suis preneur car cela permettra aussi de faire avancer le problème du bug

Voici le programme modifié, j'ai viré une bonne partie de l'affichage pour avoir une mesure précise (sinon on dépasse la VBL).
En bas à gauche, en dessus de la version (073) t'as le nombre de ticks 16,6KHz entre 2 VBL:
~333 ticks: 50 Hz
~277 ticks: 60 Hz
Fichier joint : jag5060Hz.zip

Tu as été rapide. Entre temps j'ai trouvé un autre moyen. En utilisant Pitfall... Si le jeu présente 2 barres horizontales (une en haut, une en bas) on est en 50hz et si ces 2 barres ne sont pas présentes donc le jeu prend tout l'écran on est en 60hz. Mes 2 consoles sont bien en 50hz...

DrTypoFr (./49) :
Voici le programme modifié, j'ai viré une bonne partie de l'affichage pour avoir une mesure précise (sinon on dépasse la VBL).
En bas à gauche, en dessus de la version (073) t'as le nombre de ticks 16,6KHz entre 2 VBL:
~333 ticks: 50 Hz
~277 ticks: 60 Hz
Fichier joint : jag5060Hz.zip

Sur l'émulateur Virtual Jaguar, et sans trop de surprises, le compteur joue aux montagnes russes; par contre sur l'émulateur Phoenix des russes, le compteur est steady.

DrTypoFr (./49) :
Voici le programme modifié, j'ai viré une bonne partie de l'affichage pour avoir une mesure précise (sinon on dépasse la VBL).
En bas à gauche, en dessus de la version (073) t'as le nombre de ticks 16,6KHz entre 2 VBL:
~333 ticks: 50 Hz
~277 ticks: 60 Hz
Fichier joint : jag5060Hz.zip

Et bien tu m'as motivé en ce jour férié... J'ai enfin modé ma jaguar pal continental (non uk) en 50-60hz avec un switch. J'ai pu ainsi tester la version 073 dans les 2 configurations. J'ai passé tous les niveaux 1 à 7 sans aucun problème de son ou d'image tant en 50hz qu'en 60hz. Je rappelle que sur cette même console en 50hz donc, après vérification ce matin via Pitfall lol.. Le jeu en version parallèle présentait bien les défauts sonores et visuels même sur l'image de la page d'accueil en attendant 2 minutes... La il n'en est rien. Finalement cette version fait travailler les processeurs en parallèle ou pas ?

Les preuves en images :
V 073 en 60hz:


V 073 en 50hz:


V Parallèle en 50hz :

Merci pour ce test!

Attention, la version que je t'ai filé qui mesure le temps entre 2 VBL n'affiche pas de 3D dans l'écran de titre, pas d'appel au DSP et au GPU pour la 3D. Donc ça tient!
Cependant elle a quand même l'air généralement plus stable. Dans cette version les mémoires du GPU et DSP sont mise à zéro à l'init, ainsi que les buffers écrans et ceux utilisés pour la 3D.
J'ai eu quand même des corruptions de musique pendant des tests mais ça a l'air moins fréquent.
J'ai ensuite mis les flags DSP et GPU à zéro à l'init. Ca a l'air encore plus stable, pas de corruption remarqué.
Je prépare une version 074 pour test.