Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
Au Reset, ce registre est positionné à 63. Si j'ai bien compris, cette valeur correspond exactement à la longueur d'une ligne vidéo, soit 64µs, afin d'être synchronisé avec le moniteur.
Maintenant, que se passe-t-il si l'on met 64 dans ce registre ? Ne devrait-il pas y avoir un décalage à chaque ligne ?
PS: J'ai bien essayé de chercher dans le forum avant de poster mais la recherche refuse le mot-clé "R0".
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Logiquement oui , sur un CRTC type 1 ça décale effectivement l'écran complet à droite d'un char à 64 , à 66 l'écran commence à ne plus être stable (je pense que ça doit être variable selon les moniteurs)
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
Ce qui m'ennuie, c'est que la démo d'Arkos, BigOFullODemO, positionne R0 à 64 au début et ne se décale pas sur mon 6128 mais se décale sur mon émulateur et devient du coup illisible.
Ce qui m'ennuie, c'est que la démo d'Arkos, BigOFullODemO, positionne R0 à 64 au début et ne se décale pas sur mon 6128 mais se décale sur mon émulateur et devient du coup illisible. Qui à raison ?
Vu ce qui est expliqué ici : http://www.grimware.org/doku.php/documentations/devices/crtc (section Programming the CRTC 6845), c'est donc ton moniteur qui tolère cette valeur de R0. Certains moniteurs peuvent générer un léger sifflement dans ce cas mais je n'ai personnellement jamais connu de moniteurs qui ont flanché suite à ce genre de traitement. [Je suis mal placé pour parler de ce genre de choses puisque ma dernière démo (Plasmorphy) n'était pas dans les clous niveau synchro] mais le menu et une part de Mage dans la Divine Megademo (Time 2 Go, de mémoire) utilise une valeur R0 non conventionnelle.
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
Merci Eliot, c'est vrai que cet article est une vraie mine d'info.
Donc, si je te comprends bien, j'ai de la chance d'avoir un moniteur qui supporte ce traitement, et mon émulateur est trop c.n, je voulais dire susceptible !!
Mais dans ce cas, pourquoi demander un tel timing si l'on cherche à afficher une image stable ??? Je vais demander à l'intéressé.
Dans tous les cas, je tiens à vous remercier pour vos réponses ou vos non-réponses qui me permettent d'avancer
Ah oui, dernière question, pourquoi ne pas limiter R0 à 63 ?? Comme cela, plus de problèmes de timing sauf pour générer du bruit.
Inscription : 15 Oct 2007, 02:49 Message(s) : 402 Localisation : Les Sucres en Morceaux
J'ai déjà eu entre les mains des moniteurs ne supportant pas RO>63 (pas d'image lisible à l'écran). Ca dépend du réglage (modifiable en démontant l'écran). Il faut effectivement respecter ce timing pour avoir quelque chose de "propre" (fonctionnel sur tous les écrans, tolérants ou non).
Il est arrivé que certaines prods dépassent pour plusieurs raisons. - Soit moi, parce que je suis un cochon (R0=127 dans le loader barbare de ClimaxG : Hsync seulement 1 ligne sur 2, pour profiter de &8000 comme écran malgré le système juste après) - Soit certains codeurs ignorant cette nécessité (encore de nos jours), parfois combiné avec l'espoir de gagner 1 NOP par ligne pour R0=64 par exemple. Cela se cumule à chaque ligne pour faire des VBL plus longues de 312 microsecondes... si le moniteur est d'accord. Le record est battu par les demos de Chany allant je crois jusqu'à 66 NOPs et ne fonctionnant sur aucun de mes moniteurs et improjetables lors du CPCinoche (son moniteur personnel était certainement très tolérant). Mais même dans ce cas, l'image est moins stable (léger scintillement). - Il me semble aussi que "Maurice aime les boules" utilisait ça pour avoir une configuration d'écran permettant de gratter sur le calcul d'adresse de la ligne suivante (du bloc 7 au bloc 0), à confirmer.
Inscription : 28 Août 2008, 23:41 Message(s) : 258
C'est surtout très utile pour l'affichage de sprites
Si on met R0=64, cela permet de mettre R1=64 et donc d'afficher 128 octets par ligne (ce qui n'est pas très cohérent au niveau du crtc, puisque R0 est relatif à 0 (donc 64 signifie qu'on a 65 µsec par ligne) et R1 est relatif à 1 (donc 64 représente 64 words)) (et on ne peut pas mettre R1>=R0 car l'algo interne du crtc ne change plus de bloc)
Et si on a 128 octets par ligne, il n'y a pas de débordement sur le poids fort de l'adresse. On peut donc se contenter de faire un INC L (en supposant le pointeur vidéo dans HL) au lieu d'un INC HL à chaque fois qu'on change d'octet, ce qui fait gagner 1 µsec à chaque fois. (INC L sur un pointeur de C000 à C07F, C080 à C0FF, C100 à C17F, ...)
Même principe pour les jeux qui utilisaient des écrans de 64 octets (R1=32) mais du coup, l'écran est "petit" en largeur.
Sinon, pour éviter de mettre R0=64 et d'avoir 128 octets par ligne, il reste la rupture pour chaque caractère, mais c'est sportif en terme de synchro si on n'a pas du code en temps fixe...
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
Merci pour vos réponses Supersly et Longshot
Même si je n'ai rien compris à l'explication de Longshot, hormis le fait que cette configuration permet d'optimiser la vitesse du code, je découvre que l'émulateur doit être également aussi tolérant que le sont certains moniteurs.
Je profiterai d'une réunion pour te reposer la question et essayer de comprendre cette fois !!
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
Fredouille a écrit :
Merci pour vos réponses Supersly et Longshot
Même si je n'ai rien compris à l'explication de Longshot, hormis le fait que cette configuration permet d'optimiser la vitesse du code, je découvre que l'émulateur doit être également aussi tolérant que le sont certains moniteurs.
Je profiterai d'une réunion pour te reposer la question et essayer de comprendre cette fois !!
En fait, c'est même pire que cela... il faut prendre les spécifications du chipset que tu implémentes (appelé datasheet aussi) et les coder tel quel dans l'émulateur. ensuite rajouter les spécifications de la carte mère CPC (qui peut ne pas avoir cablé certains ports par exemple, ou un léger ralenti de notre z80 parce qu'on utilise le bus par intermittence pour un autre chipset...) et tu obtiens l'émulateur parfait...qui donnera un vrai CPC en virtuel !!!
si tu ne fais qu'adapter ton émulateur lorsqu'un programme passe pas, tu risques d'avoir toujours le risque de ne pas avoir correctement emulé un chipset (exemple FDC ou CRTC) et donc d'avoir un jeu, une démo ou un prg qui ne marche pas !
le pb de l'émulation CPC reste les chipsets amstrad, où les datasheets n'ont jamais été publié... et l'émulation du CPC+ où tout est intégré (presque) dans l'ASIC est donc très limité...à cause de ça !!!
vivement que quelqu'un dissèque un ASIC ou les CRTCs pour nous donner les vrais spécifications... avec à la clé, peut-être des nouvelles possibilités insoupçonné pour les game- ou les démo-makers !
Inscription : 26 Nov 2008, 10:04 Message(s) : 174 Localisation : Saint Ouen l'Aumône
Et bien pas tout à fait. Le moteur de l'émulateur a été écrit pour fonctionner dans tous les cas nominaux, c'est-à-dire ceux utilisés par les développeur de l'époque afin que leurs productions s'adaptent à toutes les configurations... dans la mesure du possible. Ce qui fait que la plupart des jeux tournent presque sans problèmes.
En ce qui concerne les démos, c'est un peu différent car les démomakers se permettent quelques fois des configurations exotiques et parfois mêmes farfelues.
Ces cas d'utilisation n'ont pas été prévus et j'essaie juste d'ajouter ces conditions particulières au moteur existant. Bien sûr, cela peut affecter le fonctionnement normal, mais c'est pour cela que les tests de non-regression ont été inventés.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 94 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