J'ai fait une petite routine qui change les couleurs de la palette en adressant directement le Gate Array, je voulais savoir qu'est-ce qui fait que les couleurs sont effectives pendant surement 1 balayage écran et qu'ensuite elles repassent aux anciennes valeurs ?
Je pensais qu'il fallait désactiver une interruption (en $0038) mais apparemment ce n'est pas ça... (ou je m'y suis mal pris...).
Merci de votre aide
_________________ Rétro coder fou : Z80 : Amstrad CPC / MSX / ZX Spectrum -- 6502 : C64 / VIC20 -- 68000 : Amiga Mon site dédié à ma passion pour la programmation : http://majikeyric.free.fr
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
majikeyric a écrit :
Salut,
Je continue mon immersion dans le monde CPC/Z80,
J'ai fait une petite routine qui change les couleurs de la palette en adressant directement le Gate Array, je voulais savoir qu'est-ce qui fait que les couleurs sont effectives pendant surement 1 balayage écran et qu'ensuite elles repassent aux anciennes valeurs ?
Je pensais qu'il fallait désactiver une interruption (en $0038) mais apparemment ce n'est pas ça... (ou je m'y suis mal pris...).
Merci de votre aide
effectivement, le firmware restaure les couleurs à chaque vbl (à la première interruption si ma mémoire est bonne...)
normalement pour désactiver les interruptions il faut coder :
Code :
di ld hl,(&0039) ; si on veut conserver l'ancienne addresse d'interruption sachant qu'il y a &c3 en &38 ce qui correspond à l'instruction jump &xxxx ld (save_adr_int),hl ; on mets de côté sinon, ces deux lignes sont inutiles ! ld hl,&c9fb ld (&0038),hl ei
sachant que &fb = ei &c9 = ret et c'est ce qui va se trouver en &0038
Effectivement avec un simple Disable Interrupt cela fonctionne
Dans un premier temps je n'arrivais pas à voir la différence car dans ma boucle principale j'appellais le vecteur : MC_WAIT_FLYBACK pour me synchroniser avec la VBL. Apparemment cet appel doit re-lancer les interruptions car les couleurs étaient aussi ré-initialisée.
Pourquoi la solution de Megachur ne fonctionne pas ? Il y a des interruptions qui ont un autre point d'entrée qu'en $0038 ? Et si on passe en IM1 cela ne devrait pas être le cas ?
_________________ Rétro coder fou : Z80 : Amstrad CPC / MSX / ZX Spectrum -- 6502 : C64 / VIC20 -- 68000 : Amiga Mon site dédié à ma passion pour la programmation : http://majikeyric.free.fr
Pourquoi la solution de Megachur ne fonctionne pas ? Il y a des interruptions qui ont un autre point d'entrée qu'en $0038 ? Et si on passe en IM1 cela ne devrait pas être le cas ?
C'est une super question. Par défaut en IM1 oui le point d'entrée est en #38. Ceci dit, tu continues à conserver et appeler les vecteurs systèmes; ces vecteurs systèmes switchent la ROM basse (celle de #0000 à #3FFF, c'est là que tu vas trouver la plupart des routines systèmes hors basic); si jamais ton interruption arrive pendant que cette ROM basse est sélectionnée, ce qu'on trouve en #38 c'est la ROM et pas ce que t'as modifié en RAM; et donc il s'y trouve en #38 le JP habituel vers l'interruption standard du système.
Pour faire simple, je suggère: soit tu conserves le système sans le modifier (1), soit tu supprimes complètement le système (2). Explicitement: (1) changer le mode et couleurs par CALL #BC0E #BC32, ton wait VSYNC par #BD19 etc (2) oui sans système fais des OUT(7Fxx) pour changer le mode et la couleur, ré-écris #BD19 etc
(...)en évitant d'appeler les vecteurs systèmes après (...) les interruptions arrivant devraient être schinté or mes couleurs sont quand même ré-initialisées.
Je tente: ok, tu n'appelles aucun vecteur système, donc quelquechose doit switcher la ROM basse. C'est par exemple le cas si tu reviens au basic (tentative avec la boule de cristal: tu LOADes en #6000, puis call #6000 avec RET final et "Ready" du Basic à la fin?). C'est sinon un test rigolo ( (c) Madram de visu en 2001) à faire direct sous basic: INK 0,1,3:SPEED INK 5,5 puis POKE &38,&C9 et çà clignote encore!? comprendre ça et le reste viendra tout seul.
Retour à ton code: y'a quoi ensuite? si c'est LOOP JR LOOP çà marchera; tu dois avoir autre chose derrière...
Pour avancer sinon, les breakpoints dans Winape (à défaut de watchpoints). On sait sur 6128 qu'en #38 c'est JP #B941. Place donc un BREAK en #B941 et zyeute comment ce fut appelé et l'état de la ROM basse, activée ou non.
Quand tu remets le Ei, tu réautorises les interruptions d'où le problème.
Non car toutes les interruptions arrivant en $0038 ne font qu'exécuter une EI et un RET et donc pas de re-init par le firmware des couleurs (enfin normalement).
_________________ Rétro coder fou : Z80 : Amstrad CPC / MSX / ZX Spectrum -- 6502 : C64 / VIC20 -- 68000 : Amiga Mon site dédié à ma passion pour la programmation : http://majikeyric.free.fr
Pour avancer sinon, les breakpoints dans Winape (à défaut de watchpoints). On sait sur 6128 qu'en #38 c'est JP #B941. Place donc un BREAK en #B941 et zyeute comment ce fut appelé et l'état de la ROM basse, activée ou non.
Je vais y jeter un oeil!
_________________ Rétro coder fou : Z80 : Amstrad CPC / MSX / ZX Spectrum -- 6502 : C64 / VIC20 -- 68000 : Amiga Mon site dédié à ma passion pour la programmation : http://majikeyric.free.fr
Ce code je l'exécute par l'intermédiaire d'un snapshot SNA que j'envoie dans WinAPE.
Si j'exécute le code à partir d'un DSK (RUN"..."), ça fonctionne comme il faut : la nouvelle palette reste bien.
Je pense que par défault mon SNA à la ROM basse d'activée non ? c'est un snapshot du prompt au démarrage de l'ordi dans lequel j'ajoute mon code pour l'exécuter.
le RUN doit faire quelque chose au niveau de la config mémoire aussi non ?
_________________ Rétro coder fou : Z80 : Amstrad CPC / MSX / ZX Spectrum -- 6502 : C64 / VIC20 -- 68000 : Amiga Mon site dédié à ma passion pour la programmation : http://majikeyric.free.fr
A toi de le vérifier, comme un exercice d'utilisation de Winape, car Winape a ces informations et bien d'autres: rom/ram sélectionnées, palette, registres du crtc,...
majikeyric a écrit :
le RUN doit faire quelque chose au niveau de la config mémoire aussi non ?
Oui. Pour preuve: un programme binaire peut être chargé et démarrer disons en #1000, donc quand tu le RUNnes forcément on déselectionne toutes les ROMs (basse, haute) avant le JP vers l'entrée du programme en #1000 dans l'exemple.
Inscription : 13 Jan 2010, 14:25 Message(s) : 2270
Si je m'abuse, lorsqu'on fait un RUN d'un fichier binaire le FW passe l'écran en bleu. (comme un BORDER 1:INK 0,1) Pour contourner cela, il faut faire un loader BASIC.
Si tu veux que ça fonctionne avec ton sna, ton changement de palette doit avoir lieu durant ta boucle (.loop). Voilà, sinon c'est normal que ca ne fonctionne pas dans ce cas la. Si tu avais dans l'idée de faire des splitrasters, supprime bien le "ei"
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 54 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum