Samuel Devulder a écrit:
Quelques info sur les interruptions:
IRQPT est appellé à chaque IRQ. Cela peut venir du timer, du clavier ou d'autres choses. TIMEPT est appelé uniquement quand le moniteur détecte que l'IRQ vient du timer.
Autrement dit, du 6846 ?. Du coup, est il vraiment nécessaire d'indiquer l'adresse de sous routine pour le TIMER ET pour n'importe quel IRQ ? (Si ça vient du clavier par exemple, alors que la routine d'affichage de sprite ne dépend que du timer...).
Citation:
Le registre de status du timer est utilisé pour modifier son fonctionnement (un coup, répétitif, utilisation du diviseur de fréquence ou pas, etc). La doc du timer mc6846 est >>
ici<<. Attention le mc6846 est très polyvalent, il contient de la ROM (utilisée par certains thomson, mais pas tous), un PIA servant à faire des entrées sorties, etc. A noter, qu'on a découvert que sur certains thomson, le mc6846 n'en était pas un mais un clone fait par eu même qui ne contient pas tout et ne réagit pas de la même façon quand on change la période des interruptions (une histoire de -1 qui ne se fait pas dans le clone.)
J'ai cette doc en partie dans les manuel technique des TO8 à TO9+. En effet ils disent que la ROM de 4 bit du 6846 n'est utilisé apar aucune des machines. En revanche, ils ne précisent pas si c'est un faux 6846. Et apparemment, le registre du PIA n'est pas utilisé de la même manière entre le TO8 et le TO9 (certaines fonctions sont émulées par le gate array page)
Ce que tu appelles "Registre de Statut" ici est bien le registre contrôle timer en E7C5 ? Ce que tu décris ressemble + à un controle du clavier... A ce propos je m'interroge sur la possibilité d'utiliser le buffer clavier quand on est dans la routine d'interruption... Je me demande si les infos du clavier restent suffisamment longtemps pour être traité en début de routine (idem pour les manettes ou la souris)
Citation:
CC et b5 de STATUS ($6019) n'ont pas grand chose à voir. STATUS bloque de façon logicielle les interruptions TIMER (mais les IRQs ont bien lieu: le processeur est interrompu). Le bit "'i" de CC bloque lui les IRQ (toutes, et pas juste celles issues du timer) au niveau processeur (matériel). Le procersseur n'est pas interrompu dans son travail. Le bit "f", c'est pareil sauf qu'il bloque les FIRQs et pas les IRQs.
J'ai regardé les spécificité du 6309 d'Hitachi hier, pour lequel le FIRQ sauvegarde tous les registres. Ce proc est intéressant. C'est du 16/32 bits en fait (au niveau des accumulateurs) même si le mode 8/16 bits du 6809 est toujours possible.
En fait "I" et "F" sont prioritaire comparé au registre "STATUT", qui, de toute façon, si I est en mode "non", fera que si on change le STATUT de manière logiciel (bit 5) ça ne fera rien j'imagine.
Citation:
IRQ et FIRQ sont des pinoches sur le processeur pour déclencher une interruption IRQ ou FIRQ.
Pinoche ? Qu'est ce que c'est ?
Pour IRQ et FIRQ j'avais compris le fonctionnement, c'était décrit dans les docs. Et ça vient du matériel (et pas du logiciel donc)
Citation:
SWI (&2 &3) sont des instructions processeur faisant une interruption d'origine logicielle. Tout comme pour l'IRQ le processeur va alors sauvegarder son état complet et appeler une routine de service. En fin de routine de service on retourne par RTI qui fait reprendre le processeur juste après le SWI en restaurant tout son état. C'est typiquement utilisé pour appeler l'OS sous-jacent (OS9, ou même la routine MO). Perso je trouve ca lourdingue, car sauver l'état complet du processeur est super coûteux en cycles, mais cela a du sens dans le cas d'un OS multitâche interruptible comme OS9 (SWI est atomic au niveau du processeur).
[/quote]
Je pense que tout ça est géré par les routines internes du TO8 pour lesquel ils appelle la routine indiqué par les adresse $6021 et $6027 (et je me demande pourquoi il faut l'indiquer 2 fois! Seule celle du timer me parait nécessaire).
Une vingtaine de cycle pour SWI et un peu moins pour les 2 autres, c pas énorme, il faut réfléchir au contexte... La routine appelée utilise largement + de cycles (en tous cas pour les jeux vidéos avec animations). Et c'est quand même largement utilisé dans un système multitâche (comme OS9), il est important de sauvegarder tout le contexte ici. D'ailleurs je pense que si j'additionne l'ensemble des opérations effectués par ces interruption, je pense que ça dépasse le nombre de cycles de l'interruption elle même (comme FIRQ, 11 cycles pour faire tout ça, c'est vraiment pas énorme).
Citation:
Les IRQs sont détournables par l’utilisateur en utilisant l'indirection $6021-22. La partie spécifique au timer en utilisant le $6027-28. Comme ce sont des routines gérées par le moniteur, on ne reprends pas par SWI, mais par un saut en $E830 où la rom poursuivra la fin de traitement (comme relancer le timer si l'interruption vient du timer). Le FIRQ est détournable avec l'indirection en $6023-24, SWI1 avec l'indirection $602f-30. SWI2 & SWI3 ne sont pas détournables avec les ROM thomson.
Du coup, il n'y a rien à faire comme par exemple sauvegarder les adresses par défaut de la routine du timer ?
Citation:
Voilà, je pense avoir répondu à tes interrogations sur le sujet.
Oui à part celle que j'ai ajouté ici. Notamment la nécessité de donner le pointeur en IRQPT pour un truc qui ne concerne que le timer (en plus, ça pourrait être un traitement différent, par exemple, la lecture du LEP).