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