JERRY Interruptions & Cie. - Page 1

Bonsoir.
En "étudiant" le code de JERRY dans l'émulateur VJ, j'ai trouvé des choses étranges pour les Timer 1 et Timer 2 et je penses avoir une poignée de fixes.
J'utilises mandel.cof pour mes tests mais la démo est importante et je cherches du code beaucoup plus petit, pour me faciliter le tracing et la compréhension dans ce qui se passe dans VJ. Genre un affichage simple de valeurs génères par les Timers.
Est-ce que quelqu'un aurait ce genre de choses? De manières générales, tout ce qui a trait a du code simple jouant avec les interruptions m'intéressent également.
Merci.

Le seul code que j'ai c'est un prog de test pour le DSP de la jagFPGA qui fait juste que les démarres pour me permettre de visualiser sur modelsim si les compteurs sont corrects..

Je ne pense pas avoir de codes qui les utilisent

Peut-être que le player audio de Zero utilise les timers pour la lecture des pads et est suffisamment simple ?

Non, je n'utilise pas les timers pour lire les pads, mais l'interruption I²S (ça évite le risque que l'écriture des registres audio soit retardée par une interruption timer qui tomberait au mauvais moment).

Du coup je n'ai pas non plus d'exemple sous la main...

Merci pour vos réponses. Je comprends, je vais essayer de me faire un bout de code "test-case".

Mes investigations dans JERRY viennent d'un "travail" d'approche pour l'intégration d'un Profiler, CPU pour le moment mais ca pourrait s'appliquer aussi au RISC.
VJ est loin d'être précis mais ca peut me donner un ordre d'idée pour le profiling de Quake 2.
En regardant comment interfacer tout ce petit monde dans l'émulateur, c'est la ou je suis tomber a explorer le source de JERRY dans VJ et de trouver des trucs bizarre.

hello

si tu parles bien des timer 1 et 2, mon player audio les utilise
I2S pour replay des samples
timer 1 pour lecture du module
timer 2 pour lecture des pads

https://github.com/ericde45/LSP_Jaguar/blob/main/lsp_and_sound1.s

Merci pour le lien. Je vais voir comment récupérer les bouts dont j'aurais besoin.
J'ai 2 fixes de prévus pour les inits et resets des Timer 1 et Timer 2.

Je voulais reprendre mon idée d'intégrer un Profiler dans VJ-Rx, et j'ai voulu intégrer mes fixes pour les timers de Jerry.
Je me suis fait une Git branch pour tester le code, rajouter des viewers pour voir le contenu des registres de Jerry et j'ai trouver encore des trucs manquants ou étranges venant de VJ.

J'ai une question sur les registres JPIT1 a JPIT4 en read only, j'ai vu que des demos s'en servent pour afficher le nombre de millisecondes par exemple. De ce que je peux lire dans les documents.
1) They are readable, this is really for chip test purposes, but they might be used by the DSP to measure short events with precision.
2) The dividers, like the pre-scalers, are down counters which are loaded when the register is written and when they reach zero. When they reach zero they may interrupt either of the DSP or the CPU.

Comment ces registres font pour etre decrementer? Est-ce que quelqu'un pourrait m'expliquer comment cela fonctionne en read only?

Jamais testé, mais d'après ce que je comprends de la doc, ils sont décrémentés automatiquement par le hardware à chaque cycle d'horloge, et réinitialisés à la dernière valeur écrite après avoir atteint 0. Donc si tu écris 3 dedans par exemple, le compteur va prendre les états successifs 3, 2, 1, 0, 3, 2, 1, 0... (donc une séquence de longueur 3 + 1 = 4, comme c'est expliqué).

Bien, ok, merci,
Je vais rechecker si une fonction cycle d'horloge RISC existe déjà dans l'émulateur.
Pour le moment, chaque timer est géré par un callback qui (semble) se déclencher selon la formule de calcul reporté dans les docs.

Si un jeu, ou une démo, interroge les registres des timers en read-only, VJ retournera toujours les mêmes valeurs vu qu'elles sont pas décrémenter comme escompter. Ca pourrait expliquer en partie les soucis de compatibilités de VJ.

dilinger (./9) :
Pour le moment, chaque timer est géré par un callback qui (semble) se déclencher selon la formule de calcul reporté dans les docs.

Oui et c'est intelligent. Si tu fais une décrémentation + vérif à chaque cycle d'horloge, tu vas taxer facilement 100-200+ millions de cycles par seconde (25 MHz X cycles pour appeler ton callback, décrémentation, check et restaurer l'exécution). Bon de nos jours on s'en fout probablement, mais pour l'efficacité, normalement il faut faire comme ils font pour les timers. Tu notes la dernière valeur qui a été écrite et quand (donc il te faut un "global cycle counter"), et quand le jeu va lire la valeur, tu retournes "last written value" - ("global cycle counter now" - "global cycle counter at last write").

Brunni (./10) :
Oui et c'est intelligent. Si tu fais une décrémentation + vérif à chaque cycle d'horloge, tu vas taxer facilement 100-200+ millions de cycles par seconde (25 MHz X cycles pour appeler ton callback, décrémentation, check et restaurer l'exécution).

Tout a fait, et je comptes bien garder la solution des auteurs de VJ.

Brunni (./10) :
Bon de nos jours on s'en fout probablement, mais pour l'efficacité, normalement il faut faire comme ils font pour les timers.

Ca dépend du HW peut-être; a mon humble niveau, j'ai un vieux laptop qui commence a me lâcher tranquillement pas vite. N'ayant pas de tunes pour en acheter un autre, je vais essayer de rester dans l'efficace.

Brunni (./10) :
Tu notes la dernière valeur qui a été écrite et quand (donc il te faut un "global cycle counter"), et quand le jeu va lire la valeur, tu retournes "last written value" - ("global cycle counter now" - "global cycle counter at last write").

Merci pour cette proposition.

Et dire qu'au début je cherchais juste a me rajouter un profiler dans VJ-Rx...