Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
Je suis en train de me faire un simulateur CRTC / Gate Array / Z80 (je pensais pas devoir faire toutes les instructions au départ, mais si ) pour tester certains effets.
je simule donc l'appel au GA à 16 Mhz (CK = clock) en gros comme cela :
+ l'extra wait rajouter par AMSTRAD avec le GA si on fait un I/O Port read or write en CPU_CK=1 !!!
D'après les essais que j'ai pu faire, c'est le timming le mieux : celui qui donne un timming à 3,3Mhz pour le Z80 (64 nops par ligne) et permet l'affichage avec CRTC !
pour l'AY je ne sais pas du tout où le positionner en terme d'appel !
Mon gros problème c'est que je n'ai aucun moyen de vérifier si ce timming est exacte sur un 'vrai' cpc car je ne n'ai pas d'oscilloscope !!!
Est-ce que quelqu'un peu m'aider à valider ce timming d'appel des différents composants par le Gate array ? Il est possible que les appels soit différents selon les GA (ou l'ASIC) ?!
Je vous remercie par avance de votre aide et de votre passion cpcienne !!!
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
Euh, je viens de voir cela sur la page de Grim :
Code :
If the counter>=32 (bit5=1), then no interrupt request is issued and counter is reset to 0. If the counter<32 (bit5=0), then an interrupt request is issued and counter is reset to 0.
If the counter>=32 (bit5=1), then no interrupt request is issued and counter is reset to 0. If the counter<32 (bit5=0), then an interrupt request is issued and counter is reset to 0.
Et somme tout c'est assez embêtant, je m'explique: pour un effet de démo commençant en haut de l'écran, et requérant une synchro au NOP-cycle près, généralement on attend l'interruption à la VBL par HALT, avec un code similaire à EI:RET en RST#38
Ce même effet maintenant, disons qu'on le veuille plein-écran; on est généralement en DI sur les quelques 272 lignes de l'écran visible; et c'est là que le bât blesse: "en bas" de l'écran, y'a pas 32 lignes; donc un EI éventuel (ou le out équivalent à resetter le compteur) après l'écran visible ne permettra pas au dit compteur d'attendre 32 ou plus; donc (on y arrive), pas d'interruption de générée à la VBL et au final, pas possible avec HALT de se synchroniser à la VBL.
C'est un des trucs assez ch... qui a nécessité dans YAP! par exemple d'envoyer ce fameux OUT pour resetter le compteur "vers le bas" de l'écran visible. Y'a sans doute d'autre moyen de faire, comme la DTC: pas de synchro, tout tourne pile poil en 1 VBL. Respect!
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
ça me fait penser également au timming de nos chers CTM 64x ! est-ce qu'ils sont au standard PAL exactement ?
et sinon quel est leur timming de hsync et vsync ?
je m'explique, en gros pour l'instant je fais cela :
soit je prends la synchro venant du CRTC (via le GA), je compte la synchro (pas d'affichage), et je réaffiche. si je reste plus de deux lignes en synchro continue (après deux hsync), je suis en VSYNC (c'est parti pour n lignes de synchro verticale). Y'a qu'un signal venant du GA vers le moniteur ! pour la synchro imposé par le moniteur : si je dépasse un certains x par ligne, je déclenche la synchro du moniteur. pour l'instant, j'ai mis les valeurs standard du PAL : HSYNC BEGIN (PAL Standard : 4.7 +- 0.1 us) et // HSYNC END (PAL Standard : 12.05 +- 0.25 us) soit en timming GA : 32 et 192 environ ! si je dépasse un certains n lignes, je déclenche la synchro du moniteur.//312.5 - 26 lines vsync standard pour le PAL. (j'ai pas encore codé l'interlace, juste un speudo interlignes) avec ces timmings j'ai certains programmes qui utilise le CRTC (même en basic) où je dois régler le VHOLD pour que l'écran soit stable... du coup, je me dis que les moniteurs CTM sont peut-être un poil plus tolérant sur la durée de VSYNC ?
autre question, j'ai compris qu'il ne pouvait y avoir qu'une VSYNC par frame !
Merci à tous de votre aide, et en particulier notre maître du CRTC à la retraite : Overflow !!! pour l'instant aucune de tes démos ne tournent sur mon machin... j'ai encore à faire progresser mon simulateur !
Actuellement, je ne suis pas sur de comment sont les timings du moniteur : J'ai développé un algo de type "usine a gaz", qui permet de faire marcher la plupart des trucs (mais que je considère comme à revoir).
Par contre, concernant le VSync, le signal peut être généré plusieurs fois par frame. Si un seul doit être correctement positionné (timé) pour avoir un écran stable, on peut en avoir un autre en plein milieu. La partie 6 de "The demo" en présente un, notamment, mais le fond de l'écran étant noir, elle ne se voit pas. Par contre, quand on reload plusieurs fois le SNA en pj, on se rend compte que, de temps en temps, les deux parties d'écran sont inversées : Le moniteur s'est calé sur l'une ou l'autre de ces zones de synchro.
Concernant les timings de Hsync : C'est un peu complexe et apparemment assez flexible : Quelques demos proposent des frequences horizontales de 65 us, et d'autres font varier la position du signal HSync (la partie 5 de the demo, je crois - Dans cette megademo, on a décidement tout pour tester en profondeur un emulateur !). Il semble dans ces cas que le moniteur se recale correctement également.
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
Utiliser un émulateur pour tester des comportements de VSync, c'est un peut une blague en fait ?
Ce signal doit être généré par le CRTC toutes les 20ms en 50Hz. (19968μs exactement, d'après Grimware)
Lorsque le canon à électron a fini de balayer l'écran, il remonte sans rien afficher (Vblank) puis est "retenu" (Vhold) le temps de recevoir de la part du CRTC le signal de synchronisation. (VSync) Si Vsync n'est pas envoyé durant cet instant, alors c'est le moniteur qui déclenche automatiquement en fonction de Vhold... Ce qui va provoquer un effet de déchirement de l'image (tearing), car l'affichage n'est plus synchronisé avec le CPC.
Le GA ne génère pas la VSync, mais la reçoit de la part du CRTC et se synchronise dessus. (génération de 6 interruptions chaque frame, soit toutes les 52 rasterlines)
Si Vsync n'est pas déclenchée au bon moment, ça peut provoquer des affichages hasardeux. Le mieux étant de potasser les datasheets des différents CRTC.
@TotO : effectivement tu as tout juste... mais ce que je disais c'est que c'est le GA qui envoi le signal de SYNC (=crtc.HSYNC|CRTC.VSYNC) au moniteur par un seul fil ! donc il faut compter... soit c'est une hsync (au bout d'un certains compteurs) puis une fin de hsync. à la fin de la hsync, il faut rajouter le h-hold ! soit si le signal reste actif plus de deux lignes (1024*2 en compteur GA ou 64us*2) alors on considère que c'est une vsync. à la fin de la vsync, il faut rajouter le v-hold !
bon, c'est expliqué dans le pdf.
-> J'espère qu'un passionné de cpc qui a un oscillo et un cpc sous la main pourra me confirmer les timmings GA/CRTC/RAM/CPU ?
Inscription : 12 Juin 2008, 20:29 Message(s) : 1726
Lone a écrit :
Hello,
Voila des problématiques qui me parlent...
Actuellement, je ne suis pas sur de comment sont les timings du moniteur : J'ai développé un algo de type "usine a gaz", qui permet de faire marcher la plupart des trucs (mais que je considère comme à revoir).
Par contre, concernant le VSync, le signal peut être généré plusieurs fois par frame. Si un seul doit être correctement positionné (timé) pour avoir un écran stable, on peut en avoir un autre en plein milieu. La partie 6 de "The demo" en présente un, notamment, mais le fond de l'écran étant noir, elle ne se voit pas. Par contre, quand on reload plusieurs fois le SNA en pj, on se rend compte que, de temps en temps, les deux parties d'écran sont inversées : Le moniteur s'est calé sur l'une ou l'autre de ces zones de synchro.
Concernant les timings de Hsync : C'est un peu complexe et apparemment assez flexible : Quelques demos proposent des frequences horizontales de 65 us, et d'autres font varier la position du signal HSync (la partie 5 de the demo, je crois - Dans cette megademo, on a décidement tout pour tester en profondeur un emulateur !). Il semble dans ces cas que le moniteur se recale correctement également.
je comprends que lorsque le GA envoie le signal de SYNC correspondant à la VSYNC (issu du CRTC), le moniteur se mets en VSYNC... cependant, il ne fait le retour à zéro (x=0 et =0) que lorsqu'il a dépassé son compteur de ligne max (ex pour 312,5 lignes, 288 lignes+24,5 lignes pour le retour) ?
Excellente question, qui nécessiterait sans doute un oscillo pour avoir la réponse :
Soit c'est effectivement ce qui se passe, soit c'est le GA qui, pendant la durée ou il génère le vsync, va "couper" l'envoi des données pendant ce laps de temps (26 lignes si je ne m'abuse ?)
Côté moniteur, n'oublions pas non plus que nous ne sommes pas dans le domaine de l’électronique numérique, il doit s'agir plus de niveau que de compteurs, concernant la vsync, entre autre.
La documentation concernant le CRTC (et le VDU sur ce point précis) de Pierre Guerrier est d'ailleurs très instructive .
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 48 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
Connexion
Inscription
FAQ
) pour tester certains effets.
