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.
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...
—
Zeroblog —
« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » —
Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » —
GT TurboMerci 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.
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é).
—
Zeroblog —
« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » —
Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » —
GT TurboBien, 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.
