Logicielsmoto.com

Nous sommes le 28 Mar 2024, 21:43

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 12 messages ] 
Auteur Message
MessagePosté: 18 Aoû 2020, 12:41 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Bonjour

Je met cet article à part parce que je pense que le sujet est important dans la création de jeux vidéo sur TO.

Je fais référence aux article référencés par Samuel Duvelver ici http://download.abandonware.org/magazines/Hebdogiciel/hebdogiciel_numero098/16.jpg et ici http://download.abandonware.org/magazines/Hebdogiciel/hebdogiciel_numero133/Hebdogiciel%20133%20-%20Page034.jpg, ainsi qu'à la doc du "manuel technique du TO8, TO9, TO9+" et du bouquin "assembleur 2.0 6809 pour TO8/TO9/TO9+" de chez FIL.

Les interruptions sur les TO, ibt une durée "hard" programmable. Elle se trouve à l'adresse $E7C6 (manuel FIL page 61 dans la partie "moniteur") et par défaut, a une valeur de 12499 (12500 cycles) correspondant à 0.1s (il suffit de mettre 6249 pour une interruption toutes les 0.05s soit 20 fois par seconde). Soit 8 cycles par boucle. En $E7C5 (TCR), il y a un octet indiquant "registre contrôle timer" dont on ne sait pas à quoi il sert!

Pour ce qui est de la procédure dans le manuel technique des TO (p225/226), il est écrit qu'il y a 2 pointeurs de registre pour la sous routine (au lieu d'un), celle située à $6027 (TIMEPT) qui apparemment sert pour le clignotement de curseur) et celle à $6021 (IRQPT) servant à je ne sais quoi... Pourquoi 2 pointeurs pour la routine d'interruption au lieu d'1 ?, y-a-t-il 2 types d'interruption ? Alors que je crois savoir que la seule qui intervient provient du PIA 6846...

D'autre part, il faut aussi mettre le b5 du registre STATUS ($6019) à 1 pour valider le timer... Mais il y a également le CC qui semble pouvoir remplir le même genre de fonction. Ne vaut-il pas mieux indiquer au bon régistre du CC ce qu'il faut avoir ? A ce propos, il y a IRQ, FIRQ, TIMER, SWI0, SWI1 et SWI2... Même si je comprends la différence entre IRQ et FIRQ (c'est juste un IRQ rapide) difficile de voir la différence avec TIMER, et à quoi serve les SWn...

Quoiqu'il en soit, voici le code des equates
Code:
STATUS EQU $6019 Mettre b5 à 1 pour activer l'IRQ
TIMER EQU $6027 Adresse de la routine pour le timer
IRQ EQU $6021 Idem pour l'IRQ
TCR EQU $E7C5 Registre contrôle timer (???)
TSB EQU $E7C6 Valeur (16bits) timer en nombre de 8 cycles


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 18 Aoû 2020, 14:49 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
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.

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

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.

IRQ et FIRQ sont des pinoches sur le processeur pour déclencher une interruption IRQ ou FIRQ.

Une interruption IRQ empile tous les registres sur la pile, et positionne le bit E dans du CC pour indiqué que l'état complet du processeur a été sauvegardé. En retour le RTI voit que le bit E est allumé et dépile l'ensemble de l'état du processeur pour reprendre ce qu'il faisait comme si rien ne s'était passé. La sauvegarde et récupération de l'état du processeur est un truc lent (coûteux en cycles).

Une interruption FIRQ, contrairement à l'IRQ, ne sauve pas l'intégralité de l'état interne du processeur pour aller vite (le bit E n'est pas positionné). Elle est super rapide (mais faut se méfier de ne pas changer accidentellement un registre). On l'utilise quand on ne doit pas avoir de retard entre l'activation de l'interruption et l'execution de la routine de service. Par exemple quand le photophore du crayon optique voit le rayon cathodique passer devant lui, il génère une FIRQ (rapide donc), le processeur va alors immédiatement lire les registres de l'automate d'affichage pour connaitre quel était l'octet qui était actuellement dessiné par le rayon cathodique (pour info, une ligne écran ne dure que 64µs faut pas trainer pour lire les registres de l'automate d'affichage). Il collecte cela plusieurs fois et plus tard quand l'utilisateur appelle les routines moniteur pour connaitre la ligne et la colonne pointée, la routine moniteur fait des traitements sur les données collectées par la FIRQ et en déduit le pixel pointé avec une précision de 1/8 d'octet ce qui est fortiche car 1 cycle processeur représente 1/64e d'une ligne horizontale soit entre 5 et 10 pixels de large, et pourtant on atteint la précision de 1 pixel par analyse statistique des compteurs relevés par la FIRQ. Il y a de la science la dessous.

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

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.

Voilà, je pense avoir répondu à tes interrogations sur le sujet.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 19 Aoû 2020, 12:18 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
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).


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 19 Aoû 2020, 12:28 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Pinoche = francisation de l'anglais "pin" = patte du processeur.

Je ne pige pas pourquoi tu veux indiquer 2 fois l'adresse de la routine de service. Si tu ne veux gérer que les interruptions timer (pour compter le temps par exemple), il te suffit d'utiliser TIMERPT. Exemple (ISR = Interrupt Service Routine):
Code:
* init timer isr
timeInit
  ldx   #timeIt     ; activate timer
  stx   $6027
  lda   $6019
  ora   #32
  sta   $6019
  andcc #255-$50
  rts

* stop timer isr
timeExit
  lda   $6019
  anda  #255-32
  sta   $6019
  rts

* timer isr
timeIt
  inc   timeCt+1
  bne   timeIt2
  inc   timeCt
timeIt2
  jmp   $E830

* 16bits time counter
timeCt fdb 0


Sinon pour le Hitachi c'est un peu plus subtil. FIRQ fonctionne de base comme le FIRQ du 6809 avec lequel il est compatible (et tant mieux) et ne sauvegarde pas tous les registres, mais il ya un bit dans le registre MD qui permet de le faire fonctionner comme IRQ ce qui fait que le CPU a alors 2 pattes (pinoches) d'interruptions ce qui est plus souple. Ce cpu est vraiment une Rolls avec plein de bonnes idées pour étendre le 6809. Je regrette un peu que thomson ne l'ait pas utilisé pour améliorer sa game 8 bits.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 19 Aoû 2020, 21:20 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Pinoche = francisation de l'anglais "pin" = patte du processeur.

Je ne pige pas pourquoi tu veux indiquer 2 fois l'adresse de la routine de service. Si tu ne veux gérer que les interruptions timer (pour compter le temps par exemple), il te suffit d'utiliser TIMERPT. Exemple (ISR = Interrupt Service Routine)


C'est justement la question que je pose Samuel, parce que c'est ce qui est recommandé dans le manuel technique des TO8..TO9+ page 225-226.

Extrait du code du manuel
Code:
 ORG $7000
STATUS EQU $6019
TIMEPT EQU $6027
IRQPT $EQU $6021
 LDA STATUS
 ORA #$20
 STA STATUS
 LDX #$A000
 STX TIMEPT
 STX IRQPT

Et page 225 ils disent "L'adresse de votre programme de gestion de l'IRQ généré par le timer doit être implanté dans le registre TIMEPT ($6027-$6028) et dans le registre IRQPT ($6021-$6022)"
Je n'invente rien!


Dernière édition par Neotenien le 20 Aoû 2020, 17:55, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 19 Aoû 2020, 23:26 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
La doc n'est pas exempte d'erreurs. La preuve: petit désassemblage de ce qu'on trouve pointé en $FFF8 (vecteur de l'IRQ) sur TO7/70
Code:
FB73 B6E7C0     LDA    $E7C0               5 Lecture bit status du 6846
FB76 2B04       BMI    $FB7C               3 b7=1 ==> a-t-il généré une interruption ?
FB78 6E9F6021   JMP    [$6021]             8 non, autre IRQ => on saute à ce qui est indiqué en $6021
FB7C 44         LSRA                       2 b0=1 ==> l'interruption vient-elle de la partie timer ou d'une de ses I/O (CP1 ou CP2) ?
FB7D 2501       BCS    $FB80               3 oui ==> le timer a généré un timeout
FB7F 3B         RTI                       16/4 non ==> rien à fiche sur TO7/70: retour d'interruption
FB80 B66019     LDA    $6019               5
FB83 8520       BITA   #$20                2 bit 5 de $6019 allumé ?
FB85 2704       BEQ    $FB8B               3  non ==> gestion du timer par la rom (clignotement curseur)
FB87 6E9F6027   JMP    [$6027]             8  oui ==> c'est l'utilisateur qui gère le timer, le clignotement curseur aura lieu quand il fera le jmp $E830 (qui contient un jmp sur $FB8B)
FB8B ...clignotement curseur etc...
     ...
FBB0 BCE7C6     CMPX   $E7C6               7 On signale au timer qu'on est prêt à recevoir d'autres interruptions.
FBB3 3B         RTI                       16/4 Retour d'interruption
Sur TO8 et TO9 c'est pareil mais un peu plus complexe dans la mesure où il y a d'autres sources d'irq pouvant venir du 6846 via CP1 pour le clavier sur TO8.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 31 Déc 2020, 17:41 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Toujours avec l'incompréhension de pourquoi la durée du timer n'est pas respectée (ou plutôt réinitialisé à 12499 je ne sais où ?) sur mes dernières versions d'animation de sprite (utilisant le gate array pour l'affichage écran), alors que ça marchait avec la version sans gate array.

Code:
 LDD #6249 Timer toutes les 1/20s
 STD >TSB
 LDA >STATUT
* ANDA #251 Desactivation clignotement souris
 ORA #$20
 STA >STATUT
 LDX #FNTIMR Routine d interruption
 STX >IRQPT
 STX >TIMEPT


Ya-t-il quelque chose à mettre dans le reghistre TIMRCTL ($E7C5) ?


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 31 Déc 2020, 21:08 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Neotenien a écrit:
(ou plutôt réinitialisé à 12499 je ne sais où ?)

Pour savoir où, mets un point d'arrêt en écriture sur $E7C6 dans DCMOTO et tu verra tous les endroits où le thomson écrit un truc dedans.

sam.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 01 Jan 2021, 18:34 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Neotenien a écrit:
(ou plutôt réinitialisé à 12499 je ne sais où ?)

Pour savoir où, mets un point d'arrêt en écriture sur $E7C6 dans DCMOTO et tu verra tous les endroits où le thomson écrit un truc dedans.

sam.


Ok c'est fait.
Après l'initialisation du timer de mon code, il y a une routine qui s'exécute (1 seule fois dans toute l'application) et injecte $30D3 dans E7C6, situé aux alentours de l'adresse $F1E3 (c'est quoi cette routine ROM ?) :
Voilà ce code:

Code:
 STA <$19
 LDD $30D3
 STD $E7C6
 LDA #46
 STA $E7C5
 LSA $02,S
 ANDA $EF
 STA $02,S
 COM [$605A]
 COM <$75
 RTS

Après ca retourne en $ECE4

Mouai je pense que c'est un gros souk du à une mauvaise allocation au départ de ce code assembleur. Pour preuve, quand ça lance ce code, ça affiche un truc bizarre à l'écran pendant une seconde environ. Je ne sais pas si ça vient de l'initialisation..
Voilà le code du programme MAIN
Code:
 TFR DP,A
 STA >DPINIT
 LDA #2
 STA >BNKRM1
 JSR >CHBNK1
 JSR >VIDRAM Vidage banque 2
 LDA #3
 STA >BNKRM1
 JSR >CHBNK1
 JSR >VIDRAM Vidage banque 3
*Programme*
 LDA #0
 STA >XSPRIT
 STA >YSPRIT
 LDD #6249 Timer toutes les 1/20s
 STD >TSB
 LDA >STATUT
* ANDA #251 Desactivation clignotement souris
 ORA #$20
 STA >STATUT
 LDX #FNTIMR Routine d interruption
 STX >IRQPT
 STX >TIMEPT


Et cette partie concernant le changement de bank RAM, sélection banque vidéo...
Code:
*******************************
*Vidage de RAM Data (0)
*******************************
VIDRAM *
 LDD #0
 LDX #$A000
VIDRA0 *
 STD ,X++
 CMPX $DFFF
 BLO VIDRA0
 RTS
*******************************
*Routine changement de banque
*en RAM Logique A000-DFFF
*Via Gate Array mode page
*(TO8 MO6 et TO9+)
********************************
CHBNK1 *
 LDA >RAMDAT Registre RAM Donnees
 ANDA #224 Mise à 0 des bits 4-0
 ORA >BNKRM1 Ajout bank Ram
 STA >RAMDAT
 RTS
*******************************
*Routine changement banque RAM
*Pour Ecran Logique 4000-5FFF
*Gate Array mode page
*(TO8 MO6 et TO9+)
********************************
CHECR *
 LDA >BNKRM1 doit contenir 0,2 ou 3
 LDB #64 decalage 6b gauche
 MUL
 STB >BNKVID
 LDA >REGSY2
 ANDA #63
 ORA >BNKVID
 STA >REGSY2
 RTS

Ceci fait, apparemment le système exécute un tas de code à grands coups de JRS, JMP, RTS etc... et on tombe sur le code que j'ai donné en début de message. Alors que quand j'utilisais juste que la RAM vidéo normale (hors mode gate array donc), ça fonctionnait...
Alors je pense à la façon dont j'active le mode bm16 ici qui est peut-être en cause mais qui fonctionne ici pour l'utilisation du Gate Array. Après vérification, ça ne vient pas du passage en mode bm16 utilisé ici. Alors ça vient sans doute de l'activation du gate array... Le changement de E7C6 se fait après vidage (mise à 0) des banques mémoire 2 et 3, et cette action n'est pas en cause dans le changement d'E7C6 non plus (vérification en annulant ce même vidage)... Bon ben je ne sais pas d'où ça vient.

Bon en fin de compte je rajoute la valeur du timer en début de routine d'interruption, en attendant mieux...
Et avec ça, ça donne que l'on peut animer 5 sprites (8x16 avec transparence, 79 déplacements en 1.7s)) en 50 images/seconde. Après la vitesse globale diminue (2.3s pour 6 sprites, 2.7s pour 7 sprites, 3.17s pour 8 sprites, 3.6 pour 9, 4.1 pour 10, 4.5 pour 11 et 4.9s pour 12 Sprites.
Test sans transparence (pour le PAcMan d'ADNZ) : 4.1 s quand même! OIn ne gagne que 20% du temps en étant sans transparence... Ca montre que la routine de transparence de Samuel est vraiment optimisée, ou alors qu'il y a de l'optim à fare en dehors de la routine de transparence!!

Alors ceci en mode 50 rafraichissement par seconde (en agissant sur la valeur du Timer). Je pense que c'est un bon compromis. Faire déplacer les sprites en 24im/s en mode rapide et 12/s en mode lent ... C'est à dire avec 2 cycles timers en mode rapide et 4 en mode lent. En tous cas pour le PACMAN d'ADNZ, c'est largement jouable


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 01 Jan 2021, 20:14 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Neotenien a écrit:
Après l'initialisation du timer de mon code, il y a une routine qui s'exécute (1 seule fois dans toute l'application) et injecte $30D3 dans E7C6, situé aux alentours de l'adresse $F1E3 (c'est quoi cette routine ROM ?)
Attention c'est pas $30D3, mais le mot 16 bit stocké à cette adresse!
Code:
F1DF 9619       LDA    <$19               
F1E1 8A04       ORA    #$04               <= reset du flag "curseur visible"
F1E3 9719       STA    <$19               
F1E5 CC30D3     LDD    #$30D3             
F1E8 FDE7C6     STD    $E7C6             
F1EB 8646       LDA    #$46               
F1ED B7E7C5     STA    $E7C5             
F1F0 A662       LDA    $02,S             
F1F2 84EF       ANDA   #$EF               
F1F4 A762       STA    $02,S             
F1F6 639F605A   COM    [$605A]             <= clignotement curseur à l'écran
F1FA 0375       COM    <$75               <= sauvegarde état curseur
F1FC 39         RTS                       
Ce code fait parti de la partie de PUTC qui fait apparaitre le curseur. Donc soit toi, soit le basic envoie des appels à PUTC de façon imprévu ou altère le bit 2 de $6019 qui n'est pas dans un état cohérent, et le code ASM ci-dessus restore le tout comme il faut. Tu peux mettre un point d'arrêt en execution sur PUTC ($E803) et y voit tout les PUTC prévus par ton programme, mais aussi celui tout a fait imprévu qui commande l'affichage du curseur. Idem il faut surveiller les écritures à $6019... je pense qu'il y a un truc pas clean là dedans.
Neotenien a écrit:
Code:
 LDA >STATUT
* ANDA #251 Desactivation clignotement souris
Heu pourquoi parles tu de souris ? Le bit2 c'est justment le curseur qui clignote à l'écran. Là tu joue avec (même si c'est commenté, tu as du avoir à un moment l'envie de jouer avec), donc si ca se trouve les PUTC de ton programme s'aperçoivent d'une incohérence et passent dans la routine ASM plus haut qui remets ce bit à 1 et réinitialise le timer en conséquence.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 01 Jan 2021, 21:26 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Attention c'est pas $30D3, mais le mot 16 bit stocké à cette adresse!

Oui désolé,...

Code:
F1DF 9619       LDA    <$19               
F1E1 8A04       ORA    #$04               <= reset du flag "curseur visible"
F1E3 9719       STA    <$19               
F1E5 CC30D3     LDD    #$30D3             
F1E8 FDE7C6     STD    $E7C6             
F1EB 8646       LDA    #$46               
F1ED B7E7C5     STA    $E7C5             
F1F0 A662       LDA    $02,S             
F1F2 84EF       ANDA   #$EF               
F1F4 A762       STA    $02,S             
F1F6 639F605A   COM    [$605A]             <= clignotement curseur à l'écran
F1FA 0375       COM    <$75               <= sauvegarde état curseur
F1FC 39         RTS                       
Ce code fait parti de la partie de PUTC qui fait apparaitre le curseur. Donc soit toi, soit le basic envoie des appels à PUTC de façon imprévu ou altère le bit 2 de $6019 qui n'est pas dans un état cohérent, et le code ASM ci-dessus restore le tout comme il faut. Tu peux mettre un point d'arrêt en execution sur PUTC ($E803) et y voit tout les PUTC prévus par ton programme, mais aussi celui tout a fait imprévu qui commande l'affichage du curseur. Idem il faut surveiller les écritures à $6019... je pense qu'il y a un truc pas clean là dedans.
Neotenien a écrit:
Code:
 LDA >STATUT
* ANDA #251 Desactivation clignotement souris
Heu pourquoi parles tu de souris ? Le bit2 c'est justment le curseur qui clignote à l'écran. Là tu joue avec (même si c'est commenté, tu as du avoir à un moment l'envie de jouer avec), donc si ca se trouve les PUTC de ton programme s'aperçoivent d'une incohérence et passent dans la routine ASM plus haut qui remets ce bit à 1 et réinitialise le timer en conséquence.[/quote]
Erreur de commentaire LOL (pour la souris peut-être que je pensais à Mickey à ce moment là LOL)
Ok alors c'est parce que ce n'est pas désactivé que, peut-être ça réinitialise... Je n'utilise pas de PUTC.

Sinon j'ai mis quelques statistiquess dans mon message précédent, sur la vitesse avec un timer à 1/50s suivant le nombre de sprites transparent (en fait j'ai mis une solution temporaire, en initialisant VALTMR en début de routine d'interruption en attendant mieux). On peut animer de 5 (vitesse de 50 img/s dans ce cas) à 12 sprites (vitesse de 16 images/s). Et pour les sprites non transparents, on ne gagne que 20% en vitesse seulement!

Est ce que je t'envoie mon code complet en MP samuel pôur voir si tu peux voir d'où vient le problème ? Je ne conais pas vraiment la ROM... Je n'ai fait QUE changer 2 petites choses comparé à la versin qui marchait, c'est le changement de mode vidéo via Gate Array ($E7DC) et donc, la routine de changement de banque en $A000
et celle qui change la banque pour affichage vidéo (2 ou 3). Sinon, j'ai mis une petite routine pour mettre à 0 toutes les adresses de la banque 2 et 3 -(entre $A000 et $DFFF, même sui la RAM Vidéo ne fait que 16000 Octets et pas 16384.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 01 Jan 2021, 21:35 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
J'ai hélas pas trop de temps.. j'ai un truc sur le feu qui devait sortir aujourd'hui et qui a pris du retard...

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 12 messages ] 

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 45 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com