Les chapitres relatifs au mode "Interlace" ont été revus en profondeur, ainsi que plusieurs notions relatives au signal VSYNC (qui peut être retardé d’une ligne dans certaines situations).
Le chapitre sur les trucs & astuces a été largement complété (10 sous chapitres).
Un nouveau chapitre est consacré aux techniques de développement en temps fixe. Ces techniques sont une des pierres angulaires du travail réalisé pour créer le compendium. C’est aussi une manière d’introduire l’usage du calculateur de CPU qui est décrit dans le document.
Le module de test SHAKER 2.3, développé avec ce calculateur est actuellement disponible sur le portail Logon System. Il est constitué de 4 modules exécutables indépendants (A,B,C,D) (80 k)
Je profite de l’occasion pour remercier DManu pour notre travail collaboratif et constructif. Bien plus fidèle que tout autre émulateur CPC, AMSPIRIT simule assez parfaitement le trio « Gate Array/Z80A/CRTC » de l’ancienne génération des CPC pour les CRTC 0, 1, 2 et 4, en incluant toutes les fonctions « Interlace » (injustement délaissées jusqu’à maintenant).
Les chapitres relatifs à la synchronisation ont été revus en profondeur, notamment sur la nature du signal CSYNC envoyé au moniteur par le GATE ARRAY.
Le chapitre sur les statuts des CRTC 3 & 4 a été mis à jour avec l’identification de nouveaux états.
La version SHAKER 2.4 sera bientôt disponible sur le portail.
SHAKER démontre qu’il est désormais possible de réaliser un scrolling hardware horizontal fluide en 1 pixel mode 0 et en 1 pixel mode 1 sans recourir à du double buffering.
La prochaine version de l’émulateur Amspirit, développé par DManu, devrait tenir compte des différents travaux sur le signal composite et sa gestion par le CTM. A ma connaissance, aucun émulateur jusqu’à maintenant ne gérait le signal CSYNC en cours de ligne.
Inscription : 29 Août 2007, 12:04 Message(s) : 1991 Localisation : seine et marne 77
Longshot a écrit :
SHAKER démontre qu’il est désormais possible de réaliser un scrolling hardware horizontal fluide en 1 pixel mode 0 et en 1 pixel mode 1 sans recourir à du double buffering.
Tu peux préciser cette découverte ? Fluide comme 50fps ? Avec quels registres ?
Merci
_________________ SPS Community Expert (SPS CE) / SPS France
Le disque additionnel (SHAKER_ADDON.DSK) contient deux petits programmes de démonstration: Un exemple de rupture verticale (RVI/RVLL) pour tous les CRTC (Il a été présenté avec SHAKER 2.1) Un exemple de scroll hardware horizontal au pixel en mode 1 (50 fps / fullscreen) Le test correspondant dans SHAKER est dans le module D, test 6.
dlfrsilver a écrit :
Tu peux préciser cette découverte ? Fluide comme 50fps ? Avec quels registres ? Merci
Dans ce document, il est indiqué que le fonctionnalité curseur hardware n'est pas utilisé sur CPC et que ce sujet ne sera pas traité. Or, s'il est vrai que le signal CUDISP n'est pas connecté au Gate Array, il est en revanche présent sur le port d'extension et utilisé par au moins 2 extensions connues : la PlayCity et la Play2CPC. C'est dommage de faire l'impasse dessus je trouve.
Inscription : 28 Août 2008, 23:41 Message(s) : 261
PhilZeVibe a écrit :
Dans ce document, il est indiqué que le fonctionnalité curseur hardware n'est pas utilisé sur CPC et que ce sujet ne sera pas traité. Or, s'il est vrai que le signal CUDISP n'est pas connecté au Gate Array, il est en revanche présent sur le port d'extension et utilisé par au moins 2 extensions connues : la PlayCity et la Play2CPC. C'est dommage de faire l'impasse dessus je trouve.
Tout à fait, un truc que j'ai oublié de faire.
Je l'avais évoqué, si tu dépasses le préambule Page 17: Le CRTC dispose de registres pour gérer un curseur et lire les données envoyées par un "stylo optique". Les registres relatifs au curseur ne servent pas sur CPC, qui ne gère pas de curseur hardware, en général prévu lorsqu’un mode texte est géré. Ils peuvent cependant présenter un intérêt car la mise à jour de registres dans ou hors d'une période synchronisation, avec des petites valeurs, pourrait entrainer des conséquences sur d’autres registres. A défaut, il est toujours possible d’y stocker une valeur, comme le type de CRTC. Le fonctionnement de ces registres n'est pas abordé (pour le moment) dans ce document.
Page 239: Le curseur n’est pas géré sur CPC. Cependant, il est parfaitement possible de stocker des valeurs dans R14 et R15 et les relire ensuite.
Dans une prochaine version, je préciserais donc que : La broche CUDISP (19) est reliée à la broche 46 du port d'extension. Cela mérite d'être signalé et donc de définir la logique liée à R10. La broche LPSTPB (3) est reliée à la broche 47 du port d'extension (LPSTB=Light Pen Strobe) Il faudrait aussi que j'indique que le bit 3 de R12 du CRTC 3 correspond au 8eme bit de la donnée envoyée sur le port imprimante.
Inscription : 13 Jan 2010, 14:25 Message(s) : 2272
A noter que même si le schéma du CPC 464 fait référence au circuit HD6845SP, Amstrad utilise la dénomination des pins donnée dans la documentation des UM6845, à savoir CURSOR et LPEN et non CUDISP ou LSTRB, que se soit coté CRTC ou port d'extension.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 0 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