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

Bon là je ne sais plus quoi faire.
J'essaie de faire un jeu 3D et je rencontre un bug de corruption de mémoire très embêtant.
Le DSP fait les calculs de transformations et le mixage des samples (3 voies à 16KHz).
Le GPU fait le rendu des triangles, avec la Blitter.
Quand le mixage des sons et le rendu au GPU sont actifs, j'ai des corruptions de bouts de mémoire qui s'accumulent progressivement. Le symptôme le plus flagrant c'est des parties de samples qui sont corrompus. D'autres parties de la mémoire finissent par être atteintes: au bout d'un moment je perds l'affichage (mais j'entends toujours les sons, avec les corruptions). Puis la Jaguar semble planter complètement. Une fois j'ai même eu un écran rouge.

Si je désactive le rendu au GPU, bon on voit pas grand chose évidemment mais les sons ne sont plus corrompus. La machine reste parfaitement stable.
Si je désactive le mixage des sons, évidemment on n'entend plus rien mais la machine reste également stable.

J'ai protégé toutes les lectures en mémoire externes avec des trucs du style:
load (r0),r1
or r1,r1

Un truc que j'ai pris du code source de Doom c'est la protection des store avec indexation:
or r1,rX
store r1,(r14+5)

Ces protections avaient aidées y'a quelques temps quand j'étais sur la partie 3D. Le clipping se mettait à déconner quand j'ai rajouté le son.
Avec les protections ça a cessé de déconner. Je pensais être tiré d'affaire mais non...

Là on dirait qu'il y a autre chose. Une sortie de conflit entre la lecture des sons et le rendu au GPU/Blitter. D'ailleurs j'ai essayé un rendu pur GPU ça fait pareil, c'est pas spécifiquement le Blitter qui pose problème.

Voilà, si y'a des gens motivés je peux partager le code source.
Je joins un binaire. Il suffit de rester sur l'écran de titre et en moins de 2 minutes on finit par entendre des bruits désagréables.

Fichier joint : jag.zip

Ah oui j'oubliais: ça marche parfaitement bien dans l'émulateur Phoenix. Ca semble indiquer que c'est pas une bête histoire de pointeur qui se met à vadrouiller là où il devrait pas.

J'ai rapidement regardé, mais y a un truc que je ne comprend pas en regardant le code désassemblé :

J'ai l'impression que tu utilises le JPIT1 et donc l'interrupts Timer 0 pour écrire dans les registre LTXD/RTXD de la sortie audio ?
Je ne vois pas d'init de la SCLK non plus, du coup je ne comprends pas comment le son peux être joué à la bonne fréquence ni comment ça peut être correctement synchrone.
Normalement on initialise le SCLK et on utilise le I2S interrupt pour avoir les données parfaitement synchrone entre la lecture des valeurs dans le registre et l’écriture.
Du coup je suis un peut étonné de la méthode et que ça puisse fonctionner sur une vrai jag.

Ça expliquerai pourquoi le son se détériore avec le temps, mais ça n'explique pas le crash par contre.

je suis intéressé pour avoir le code source pour voir & comprendre un peut plus globalement (et facilement) le code.

Merci de regarder!

Oui j'utilise le timer 1 comme source d'interruption. J'écris dans les registres LTXD/RTXD pour la sortie audio.

Pour être bien précis, le son ne se détériore pas graduellement. Le son est joué correctement et le temps que le sample reboucle des parties du sample sont corrompues. Les zones corrompues augmentent en nombre au fil du temps.
Mais c'est vraiment la mémoire qui est corrompue. J'ai visualisé le contenu du sample et j'ai pu voir des morceaux se corrompre.

Voici les sources:
Fichier joint : clip054.zip

merci, je regarde

Je joins une nouvelle version des sources qui permettent de visualiser une partie du sample. Ca permet de voir les corruptions apparaître.
Le binaire .cof est dans le fichier "jag.zip" du dossier "clip".
Par défaut ça pointe sur l'adresse 0xAA1F0. La zone montrée a l'écran fait 122880 octets. Le sample total fait 658453 octets. On ne voit donc qu'une partie du sample.
J'ai trouvé empiriquement que c'est dans cette région que l'on a le plus de chance de voir des corruptions apparaitre en premier.
Par défaut on voit une bouillie de pixels verts et violets. Les corruptions se caractérisent par l'apparition de blocs avec des pixels blancs et noirs.
On peut scroller dans la mémoire avec les touches haut et bas.

Fichier joint : clip055.zip

hmm, je ne reproduis pas le problème sur la JagFPGA, du coup ça va être compliqué à investiguer
Faudra du coup que je ressorte ma jag BJL et que je retrouve les câbles et softs.


Il y avait une raison particulière d'utiliser JPIT1 au lieu de l'interruption I2S ?

J'ai regardé également rapidement le code DSP (uniquement) et il y a quelques trucs qui me semble un peu bizarre, mais je peux me tromper et puis surtout ça n'a surement aucun rapport avec le bug.

Première chose, les interruptions utilisent obligatoirement les registres de la banque 0. Du coup tu peux utiliser la banque 1 pour le programme "normal" et la banque 0 uniquement pour ton interruption. Ca te permet de ne pas être obligé de sauvegarder ou d'initialiser certains registres à chaque fois.
Je dis ça vu que la routine d'interruption initialise dès le début plusieurs registres qui ne semblent pas être modifié tout le long.
ex : timerint:
movei #D_FLAGS,r30
et
movei #L_I2S,r15

Ensuite, bon tu n'en est peut être pas à la phase d'optimisation, mais au cas où pense à l'entrelacement du code.
Par exemple au début
timerint:
movei #D_FLAGS,r30
load (r30),r29 <- wait state ici car r30 est verrouillé par l'instruction du dessus
moveq #0,r24
move r24,r25 <- même chose ici car r24 est verrouillé

Peut avantageusement être entrelacé comme :
timerint:
movei #D_FLAGS,r30
moveq #0,r24
load (r30),r29
move r24,r25

Bon alors ok ça ne fait gagner que 2 cycles mais....
Il me semble que pour l'interruption des échantillons tu prends le problème à l'envers.
Si je ne me trompe pas lors de l'interruption tu fais les calculs avant, et ensuite tu charges les registres I2S avec le résultat.
Pour la génération du son la routine du chargement des échantillons doit être la plus courte possible et n'avoir si possible aucun changement de flux ou de condition (jmp, cmp, etc.)
La moindre différence du nombre de cycle entre chaque échantillon provoquera des distorsions de fréquence ou même des craquements si par exemple tu vas lire les échantillons en DRAM et que le BUS est trop occupé.
Il faut donc dès le début de l'interruption charger les registres I2S avec les valeurs calculées dans l'interruption précédente (ou une autre routine)
L'interruption pour les échantillons devrait se comporter comme si c'était un DMA : charger les échantillons déjà calculés, FIN.

Par endroit tu fais des protections de registre (pour activer le mécanisme du scorboard quand il fait défaut) qui ne me semble pas utile (et qui peuvent faire perdre des cycles du coup puisque il devient également inutile d'entrelacer le code)

Par exemple :

movei #_timer8KHz,r21
or r21,r21
load (r21),r22

Pourquoi or r21,r21 ?
Sauf erreur il n'y a rien qui nécessite un verrouillage forcé de r21

Par contre là oui :
load (r21),r22
or r22,r22
addq #1,r22

car ici c'est en effet le "bug" de la double écriture d'un registre sans lecture préalable
r22 est écrit une première fois et sans l'instruction "or" il ne serait pas verrouillé lors de l'instruction addq et le résultat serait... inattendue


Il y a quelques endroit ou tu fais une protection également étrange :
add r22,r23 ; step
or r23,r20 ; scoreboard bug
2 choses :
1 - Pourquoi : or r23, r20 ? et pas or r23,r23 ?
Bon à priori de ce que j'ai vu r20 n'a pas d'importance à ce moment là, mais si un jour tu ajoutes du code qui utilise r20 tu pourrais passer à coté d'un bug énervant.

2 - c'est à confirmer, mais je crois que le bug du scorboard sur l'adressage indexé ne concerne QUE les instructions à très long cycle. C'est à dire.... quasiment que le DIV en fait. C'est d'ailleurs indiqué dans le documentation (long latency instruction)
Pourquoi ? Tout simplement parce que l'adressage indexé prend 2 cycles de plus qu'un LOAD (ou STORE) normal. Ducoup, le temps que l'adressage soit calculé, l'instruction précédente est déjà fini et le registre est libre et avec la bonne valeur.
Avec un DIV qui prend 16cycles je crois, s'il est placé juste avant ou en tout cas pas trop loin du STORE indexé, il n'aura clairement pas fini sont calcul et l'écriture du registre tombera après ou en même temps.
Tout ça c'est de la spéculation dans la mesure ou je n'est pas testé, je me base sur ce qui est écrit dans la doc (d'autant que celle ci parle bien de 2 cycles supplémentaire pour le LOAD indexé mais pas le STORE, mais il parait logique qu'il prenne + de temps aussi)

De la même façon il n'est pas nécessaire de protéger les registres ici :

add r22,r23 ; step
add r26,r24 ; mix left
add r27,r25 ; mix right
or r23,r20 ; scoreboard bug
store r23,(r14+CVoiceSplCpti)

.endtimerint:
or r24,r20 ; scoreboard bug
store r24,(r15)
or r25,r20 ; scoreboard bug
store r25,(r15+1)

Tous les registres concernés (r23, r24, r25) sont éloignés de leur STORE respectif, de très loin même) dont 1 qui n'est pas indexé

Bon voilà, j'ai peut être dis un tas de conneries, dans ce cas n'en tiens pas compte

Tiens ici non plus je ne crois pas que ce soit utile :

.readvoice1:
movei #Voice1,r14
or r14,r14
load (r14+CVoiceSplEndi),r21
load (r14+CVoiceSplCpti),r23

Pas besoin de protéger r14 parce que d'une l'instruction précédente est plus rapide que le calcul de l'adresse indexé, 2 le bug de l'adressage indexé ne concerne que le registre de donnée, le registre d'adresse est lui bien protégé, et 3... ben le bug ne concerne que l'instruction STORE

à bien y réfléchir je crois que le bug du mode indexé c'est surtout parce que le scorboard n'est pas capable de garder le verrouillage d'un registre data pendant plus de quelques cycles pour ce mode d'adressage.

Merci à vous deux de vous pencher sur mon problème! C'est vraiment sympa.

@SCPCD: bon, j'avoue que ça m'étonne pas que ça ne se reproduise pas sur la JagFPGA. Je pense que le bug est une bizarrerie électronique vaudou qui se reproduit uniquement avec les composants électroniques d'origine.
J'utilise le timer 1 tout simplement parce que c'est suggéré dans la doc d'Atari: "It is intended that timer one is used to generate the sample rate frequency for sound synthesis..." (chapitre JERRY, section Programmable Timers).
Je pourrais utiliser l'interruption I2S en effet.

@DEATH: tu amènes de nombreux points! Merci pour ces conseils.

Pour les banque 0 et 1, j'utilise effectivement la banque 1 pour le programme normal et les registre r20-r31 de la banque 0 pour l'interruption. Mais tu as raison, je peux ne pas recharger le registre r15 avec l'adresse du I2S à chaque fois.
Cependant pour le registre r30 il faut le recharger à chaque fois dans l'interruption. C'est indiqué dans la doc d'Atari: "Note: R30 is automatically corrupted when an interrupt occurs..." (chapitre Graphics Processor, section Interrupts).

Très bonne remarque pour la génération des échantillons: j'ai effectivement pris le problème à l'envers. Je modifierai le code dès que j'aurai résolu le bug actuel de corruption mémoire. Pour info, j'ai testé en retirant la lecture des échantillons (les loadb) et l'écriture vers les I2S: le bug se produit toujours. C'est une corruption de mémoire liée à la présence de l'interruption. C'est pas lié à la génération du son proprement dite.

Pour les protections de registres, il y en avait initialement beaucoup moins et seulement dans les endroits "logiques". Mais avec ce bug bizarre, j'en ai mis partout.

Pour la séquence:
movei #_timer8KHz,r21
or r21,r21
load (r21),r22
bon, là c'est de la paranoïa mais je suis tombé sur un bug dans une séquence similaire avec un store:
movei #_nTriAdd,r0
or r0,r0
store rNAdd,(r0)
Là si y'a pas le or r0,r0, ça déconne. Donc je fais un peu pareil pour le load mais ça sert probablement à rien. Je le retirerai si je résout le bug.

Pour les séquences du style:
or r25,r20 ; scoreboard bug
store r25,(r15+1)
J'ai vu ce genre de chose dans le code source de Doom. Il faut manifestement protéger les écritures avec un adressage indexé en faisant un OR avant.
Ca semble un problème différent de celui des instructions longues.
J'utilise un autre registre parce qu'il faisait ainsi dans Doom. C'est vrai que c'est con, ça gaspille un registre mais à ce stade je copie exactement les protections qu'on fait les autres.
Pour la séquence:
or r24,r20 ; scoreboard bug
store r24,(r15)
Oui là ça doit vraiment pas être nécessaire. Je vais le retirer.

Voilà. Tu n'a pas dit de conneries et je vais tenir compte de tes remarques. En fait la grande partie des protections bizarres et probablement inutiles du code vient du fait que je prends un excès de précaution avec ce bug bizarre.

DrTypoFr (./10) :

bon, là c'est de la paranoïa mais je suis tombé sur un bug dans une séquence similaire avec un store:
movei #_nTriAdd,r0
or r0,r0
store rNAdd,(r0)
Là si y'a pas le or r0,r0, ça déconne. Donc je fais un peu pareil pour le load mais ça sert probablement à rien. Je le retirerai si je résout le bug.

Oui là c'est peut être "normal". De ce que j'ai vu _nTriAdd est en DRAM
Donc là on peu tomber sur le bug de l'écriture en DRAM du DSP. Ce bug fait que le DSP doit être déconnecté du BUS depuis au moins 1 cycle pour pouvoir faire une écriture fiable en externe.
Le fait est qu'un cycle externe dure "longtemps" (du point de vu du DSP, et surtout pour des accès 32bit. Le DSP ayant un BUS de 16bit il doit faire 2 accès DRAM !). Et donc un accès précédent en externe (en lecture ou écriture) ayant eu lieu même plusieurs instructions avant un STORE, peu le faire foirer si le cycle externe précèdent n'est pas terminé (en tout cas c'est comme ça que j'interprète la doc).
Dans la doc la façon la plus sûr de s'assurer que le DSP est "déconnecté" du BUS, c'est de faire un LOAD externe, puis de verrouiller le registre concerné avec le scorboard puisque le DSP sera alors bloqué jusqu'à la fin du cycle mémoire du LOAD. On peut alors faire un STORE derrière sans bug.

Ici, le fait de faire un or r0,r0 alors que juste avant ce n'était pas un accès externe c'est peut être juste un coup de chance. Il y a peut être un accès externe un peu avant et le fait de gagner 1 ou 2 cycles avec le or r0,r0 (+ le mécanisme du scorboard) ajoute assez de cycle pour que l'accès mémoire externe précèdent soit terminé.

Je viens de penser à un truc. Atari indique que les registres R30 et R31 sont corrompus par l'interruption. Et ils insistent sur le R30. Et si c'était dans les DEUX banques qu'ils étaient corrompus?
Parce que dans le programme "normal" je me sers de R30 et R31.
R30 (rPtAdd) = pointeur de destination des triangles à rasteriser
R31 (rNAdd) = nombre de triangles à rasteriser.
Je pense pas que R31 de la banque 1 soit corrompu. Ca aurait des conséquences trop dramatiques, par exemple il pourrait rastériser 1 million de triangles.
Mais R30... là c'est possible. Ca copierait les triangles au mauvais endroit.
Je me sers de R30 un peu partout donc je vais pas corriger ça ce soir
Ca me parait l'hypothèse la plus probable.

Normalement r'30 et r'31 (de la bank1) ne sont pas impactés car lorsque les microcodes de l'interruption s’exécutent la bank est déjà forcé à la bank0, du coup y a que r30 et r31 (de la bank0) d'impactés.


Dans la doc timer1 est bien marqué "It is intended that timer one is used to generate the sample rate frequency for sound synthesis...", mais c'est pour le cas où l'on utilise les PWM DAC. (ce qui n'est pas le cas sur jag, vu qu'il n'y a rien de câblé dessus)
Il faut du coup utiliser la SCLK comme source d'interruption pour l'audio.
Si SCLK n'est pas initialisé, tu n'as pas de garantie que la freq défini corresponde à ce que tu attends. (je ne sais pas si le BJL, le bios jag, la skunk, jagcd, jagGD, etc utilisent tous la même freq par exemple)
Ça va peut-être aussi dépendre de ce qui a été exécuté avant.
De plus, SCLK étant la freq I2S, les échantillons seront envoyés au DAC à cette fréquence, quelque soit la freq d’écriture dans LTXD/RTXD. Il y aura donc aucune garantie que les échantillons sont lu au bon moment : il y aura probablement des échantillons envoyés plusieurs fois, une fois, voir pas du tout au DAC, et potentiellement un échantillon gauche non synchro avec celui de la droite.
Il y aura du coup des défauts "bizarres" dans le son.



Sinon, j'ai ressorti ma jag BJL, mais je ne reproduis pas ton soucis...
J'ai du convertir les différents COF en .bjl via jiffi (vu que mon uploader BJL via Catnip ne gère pas les COF), j'ai fait tourner le menu au moins 30min sur chaque version en 50Hz et je n'observe pas de corruptions...

Quel est ton environnement de test ?

Pour tester j'utilise une Skunboard rev 3. La Jaguar est une européenne mais je ne sais pas quel modèle exact c'est (je sais qu'il y a quelques variantes).

C'est très curieux que tu ne reproduise pas mon bug. Ce serait donc spécifique à mon modèle de Jag, voir la console elle-même? Aurais-je une Jaguar hantée?

@DEATH, parler d'optimisations est un peut prématuré pour le moment, mais il y a des pièges dont tu es tombés dedans

Sur une vrai Jag, les MOVEx sont en 2 cycles et non 3 (comme quasi toutes les autres instructions) du coup les codes suivants sont identiques niveau cycle :
movei #D_FLAGS,r30 load (r30),r29 moveq #0,r24 move r24,r25 movei #D_FLAGS,r30 moveq #0,r24 load (r30),r29 move r24,r25 Le MOVEI prend un cycle de plus que les autres MOVE, mais il prend 3 slot 16-bit au lieu de 1, du coup la différence de cycle est compensée et c'est garantie que le registre est ready pour l'instruction suivante.


Je pense qu'il y a effectivement plein de truc "à priori" inutile, mais n'ayant jamais vraiment joué avec le DSP, je ne saurais pas garantir ce qui est vraiment obligatoire ou pas, pour ça que je préfère l'approche de DrTypo de d'abords trouver le pb et après simplifier.

DrTypoFr (./14) :
Pour tester j'utilise une Skunboard rev 3. La Jaguar est une européenne mais je ne sais pas quel modèle exact c'est (je sais qu'il y a quelques variantes).

C'est très curieux que tu ne reproduise pas mon bug. Ce serait donc spécifique à mon modèle de Jag, voir la console elle-même? Aurais-je une Jaguar hantée?

Ma BJL est une Jaguar USA de première série modifié pour le 50/60Hz.

Faudrait effectivement voir si d'autres personnes reproduise ton problème avec une autre jag.

Peut-être voir les versions du PCB de la console?
Il y a eu 2 versions du GPU/DSP, est ce que cela pourrait être lié?

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

J'ai deux Jag BJL au besoin, donc au moins une est européenne (pour l'autre je sais plus).

Bon, j'ai modifié l'utilisation des registres pour ne plus utiliser r30 et r31 dans le prog principal. Le bug se produit toujours.
J'ai utilisé l'interruption I2S au lieu du timer1, ça ne change rien non plus.
J'ai de moins en moins d'idées.

SCPCD (./15) :
@DEATH, parler d'optimisations est un peut prématuré pour le moment, mais il y a des pièges dont tu es tombés dedans

Sur une vrai Jag, les MOVEx sont en 2 cycles et non 3 (comme quasi toutes les autres instructions) du coup les codes suivants sont identiques niveau cycle :
movei #D_FLAGS,r30 load (r30),r29 moveq #0,r24 move r24,r25 movei #D_FLAGS,r30 moveq #0,r24 load (r30),r29 move r24,r25 Le MOVEI prend un cycle de plus que les autres MOVE, mais il prend 3 slot 16-bit au lieu de 1, du coup la différence de cycle est compensée et c'est garantie que le registre est ready pour l'instruction suivante.


Je pense qu'il y a effectivement plein de truc "à priori" inutile, mais n'ayant jamais vraiment joué avec le DSP, je ne saurais pas garantir ce qui est vraiment obligatoire ou pas, pour ça que je préfère l'approche de DrTypo de d'abords trouver le pb et après simplifier.

Ah oui tiens je n'avais pas fait gaffe pour les move (en même temps c'est logique vu qu'il n'y a pas de calcul par l'ALU)

C'est vrai qu'en regardant cycle par cycle c'est chaud.... que ce soit le code entrelacé ou non on obtient des situations de colisions...
Des doubles écriture aux registres (ce qui je crois n'est pas possible), des triples accès aux registres (impossible aussi)....
J'ai même l'impression que dans le 1er cas non entrelacé le LOAD peut potentiellement se terminer après le dernier move r24,r25...

c'est désespérant.

Il faudrait une sorte d'assembleur/simulateur pour voir comment vont être exécuté les instructions à chaque cycle

Quel casse tête

DrTypoFr (./1) :

Je viens de tester le fichier COF et je ne vois aucun bug

C'est au bout de combien de temps que ça plante ou bug ??
En faisant quoi ?

j'ai laissé tourner l'intro quelques minutes, rien. J'ai "joué" quelques minutes, rien non plus.

DrTypoFr (./5) :
Je joins une nouvelle version des sources qui permettent de visualiser une partie du sample. Ca permet de voir les corruptions apparaître.
Le binaire .cof est dans le fichier "jag.zip" du dossier "clip".
Par défaut ça pointe sur l'adresse 0xAA1F0. La zone montrée a l'écran fait 122880 octets. Le sample total fait 658453 octets. On ne voit donc qu'une partie du sample.
J'ai trouvé empiriquement que c'est dans cette région que l'on a le plus de chance de voir des corruptions apparaitre en premier.
Par défaut on voit une bouillie de pixels verts et violets. Les corruptions se caractérisent par l'apparition de blocs avec des pixels blancs et noirs.
On peut scroller dans la mémoire avec les touches haut et bas.

Fichier joint : clip055.zip

J'ai essayé cette version aussi et je ne vois aucun corruption apparaître.

C'est ta console qui est buguée j'ai l'impression. Tu peux faire tourner tous les jeux sans problème ?

@DEATH: ça bug en moins de 2 minutes, on entend des bruits très désagréables dans le sample d'intro. Si on attend plus longtemps (5 minutes?), on perds l'affichage et la console freeze.

Je me demande en effet si c'est ma console qui est buggée mais SCPCD indique qu'il a eu le plantage avec sa console européenne (mais pas sur son américaine).
J'ai essayé peu de jeux récemment (juste mon jeu Fallen Angels pour voir... ça marche parfaitement bien). Je vais essayer d'autres jeux...
Merci d'avoir pris le temps de tester!

J'ai essayé Doom, Hover Strike, Iron Soldier: tous fonctionnent très bien.

Pour info je test avec une SkunkBoard V3, sur une Jaguar européenne.

Si je me fie aux numéros de série (qui n'est pas le même sur la console et sur la carte mère) ça serait :
Pour la console : une version K1 (IBM) de septembre 94
Pour la carte mère : une version K2 (IBM - Plexus) de mars 94

Après je ne suis pas sûr de se que veulent dire exactement les numéros de série.

Petit détails, je l'ai passé en 60Hz fixe.

J'ai apporté quelques modifs mais peu d'impact positifs sur le bug, c'est peut-être même pire qu'avant: l'affichage peut déconner dès le démarrage. J'ai rajouté des OR pour "protéger" encore plus de STORE mais ça ne fait rien.
Une petite modif, sur le conseil de DEATH, j'ai chargé les I2S dès le début de l'interruption. J'ai pas entendu de différence mais c'est plus propre logiquement donc je laisse comme ça.
Une autre modif plus importante: avant le 68000 demandait au DSP de faire les transformations à chaque objet et attendait ensuite que le DSP finisse à chaque fois. Vu que j'ai beaucoup d'objets avec les particules bleues, ça faisait beaucoup d'aller/retour 68000/DSP (ce que VJ n'aime pas trop d'ailleurs).
Maintenant le 68000 construit une liste d'objets avec leurs transformations respective et le DSP parcours d'un coup la liste et fait les transformations. Ca améliore légèrement les perfs.
Voici les nouvelles sources incluant le jag.zip avec le .cof.

Fichier joint : clip057.zip

J'oubliais, j'ai refais le test: en désactivant le rendu au GPU c'est stable. On a vraiment un pb de conflit d'accès au bus.

DEATH (./26) :
Après je ne suis pas sûr de se que veulent dire exactement les numéros de série.

J'ai retrouvé le document qui explique les numéros de séries, si cela peut aider.
http://pagesperso-orange.fr/jaguar-64bit/Liens/500277ra.pdf

dilinger (./28) :

DEATH (./26) :
Après je ne suis pas sûr de se que veulent dire exactement les numéros de série.

J'ai retrouvé le document qui explique les numéros de séries, si cela peut aider.
http://pagesperso-orange.fr/jaguar-64bit/Liens/500277ra.pdf

Oui c'est celui que j'ai utilisé. Mais comme il y a plusieurs numéro de série sur une Jaguar....

DrTypoFr (./27) :
Une autre modif plus importante: avant le 68000 demandait au DSP de faire les transformations à chaque objet et attendait ensuite que le DSP finisse à chaque fois. Vu que j'ai beaucoup d'objets avec les particules bleues, ça faisait beaucoup d'aller/retour 68000/DSP (ce que VJ n'aime pas trop d'ailleurs).

Dans Virtual Jaguar, le GPU est appelé dans la même boucle qui appelle le M68K. Le DSP a un diffèrent traitement, il est appelé via SDL par le SDLSoundCallBack.
Il existe aussi 2 DSP pipelines mais un seul est pris en compte. Autoriser le deuxième semble être simple mais aucune idée comment ce pipeline fonctionne. D'un autre coté, s'il n'a pas été pris en compte, c'est qu'il y a aussi probablement une raison.
C'est sur que rien ne remplacera le HW original.