Compendium !
Dans mon premier billet, j’ai évoqué un document technique dont la première version est sortie fin 2021. Quelques personnes m’ont demandé des précisions complémentaires sur ce document et sa genèse. Si vous arrivez au bout de cet article, je promet de vous refiler la recette de l'adobo dans mon prochain post.
C’est quoi ?
C’est un document que j’ai nommé «The Amstrad Cpc Crtc Compendium » et qui contient le résultat d’une étude approfondie des composants vidéos équipant les micro-ordinateurs CPC produits par la société Amstrad dans les années 80.
CRTC est un sigle pour "Cathode Ray Tube Controller". Le CRTC 6845 est un modèle de ce circuit générique utilisé par de nombreux micro-ordinateurs conçus dans les années 80 pour faciliter la mise au point de l’électronique d’affichage de ces machines. IBM l'a employé massivement dans l'IBM PC sorti en 1981, et qu'on a retrouvé dans les cartes vidéo CGA, EGA, VGA équipant les premiers PC et compatibles.
Un peu plus de 2 ans après sa première publication, en décembre 2021, le Compendium est passé de 173 pages dans sa version 1.1 à 284 pages dans sa version 1.7. Il est distribué en anglais depuis le 1er janvier 2022.
C’est un document gratuit délivré sous format PDF mais qui est néanmoins enregistré sous « Common Creative License ».
Pourquoi ?
Je suis très curieux et intéressé par les premiers systèmes graphiques. Depuis plusieurs années, je souhaitais structurer un document décrivant le fonctionnement du CRTC 6845 dans le contexte du CPC, en y associant différentes techniques utilisées dans le monde de la demoscene et par moi-même dans quelques productions.
C'est en développant un logiciel sur CPC nécessitant de la précision technique que j'ai constaté que je perdais beaucoup de temps à fouiller mes notes pour retrouver des informations et que j'étais parfois amener à refaire des tests.
Je pense qu’un document de ce type s’imposait pour servir de référence technique fiable et éprouvée à tout développeur (en m'incluant dans le lot) tout en complétant mes propres connaissances dans un document vivant.
J’ai également toujours privilégié le partage des connaissances. Le groupe Logon System a largement démontré cette philosophie depuis sa création en 1988.
Pour qui ?
Le document s’adresse à des programmeurs déjà expérimentés et/ou des développeurs d’émulateur confrontés à l’indigence des documentations techniques des sociétés qui ont produit ces circuits.
Il contient également de nombreux chapitres beaucoup moins techniques pour permettre à tous d’accéder à des informations pertinentes qui dépassent le cadre des circuits du CPC.
Comme on va le voir plus loin, on ne peut pas créer un document spécifique au CRTC sur CPC sans décrire également l’architecture de la machine et les circuits qui travaillent « ensemble », comme le Z80A (le processeur du CPC) ou le GATE ARRAY (le circuit qui pilote tous les autres circuits de la machine).
Lorsqu'il est question de programmer ces circuits, il faut également aborder la manière dont cela peut se faire concrètement. La mise en image de techniques pointues implique aussi de décrire des principes d'optimisation ou de programmation sur le CPC. Ces chapitres sont moins complexes à appréhender que la gestion des états internes de circuits comme les CRTCs. Je pense que cela rend le document assez polyvalent, certaines personnes pouvant par exemple se contenter de tirer seulement partie des méthodes d'optimisation ou de programmation en temps fixe.
Les CRTCs du CPC ?
Oui...et non!
La société Amstrad a utilisé des composants CRTC 6845 "génériques" provenant des 3 fabricants Hitachi, UMC et Mororola. Elle a également créé sa propre version du circuit dans un ASIC pour minimiser ses coûts de production. Un ASIC est un circuit spécialisé qui permet de regrouper différentes fonctions sur un même circuit. Il n'existait malheureusement aucune documentation publique sur ce CRTC « Amstrad »
Contributeurs aux projets Wikimedia
Le document fait l’impasse sur les fonctions CRTC non « exploitées » sur CPC, comme la gestion d’un curseur « hardware » ou le mode « texte », qui sont utilisés avec les IBM PC et leurs cartes CGA. Il reste toutefois exploitable pour les utilisateurs d’autres plateformes qui utilisent ou cherchent des informations sur ce composant et qui font face aux mêmes questions et sujets de compatibilité que sur CPC.
A ce titre, j’ai eu des retours très positifs d’utilisateurs de machines diverses comme le BBC, l’IBM PC ou même le VIDEOTON.
Sur IBM PC, j'ai eu des échanges constructifs avec des personnes qui ont participé à la démo AREA5150 (Hello Utterchaos & Viler) et exploitent le document.
PCem
Pour les plus curieux, Viler a publié sur son blog des recherches très intéressantes, notamment sur l'affectation des comparateurs sur une architecture "asynchrone":
Enfin, pour l'anecdote, le VIDEOTON est une machine hongroise singulière équipée d’un Z80A et disposant de très peu de ram vidéo, ce qui en fait un excellent candidat pour toutes les techniques de vectorisation de la ram vidéo et notamment la technique de rupture ligne à ligne.
Contributors to Wikimedia projects
Même si les CRTC intégrés dans ces différentes machine ne sont pas exactement les mêmes que ceux présents dans les CPC, les informations présentes dans le Compendium se révèlent être de bonnes bases de prospection et permettent de corroborer davantage les résultats énoncés par mes recherches.
Et les documentations officielles ?
Les différents fabricants du circuit, comme Hitachi, UMC, Rockwell, VTI, Motorola et bien d'autres, ont créé des documents exclusivement en anglais et communément appelés « datasheet ».
Ces documents ont à peu près tous la même structure. Certains circuits sont eux mêmes des copies de certains modèles d’autres marques et qu’on ne peut pas toujours dissocier à part avec le marquage sur le composant. On peut dénombrer quelques copiés/collés dans ces documentations.
Le cahier des charges fonctionnel était assez générique. Cependant des solutions techniques assez différentes ont été implémentées par les ingénieurs pour atteindre des objectifs "généraux" similaires.
Ils ne sont cependant pas rentrés dans le détail des solutions qu’ils ont implémenté dans leur documentation, même dans les tableaux comparatifs des circuits. On peut parfois trouver de vagues consignes sur les limites de valeurs sans que cela soit motivé, et il y a quelques erreurs (par exemple dans le document UM6845R à propos du mode interlace, figure 7).
Impossible donc avec ces documentations de comprendre vraiment ce qui se produisait dans le circuit, et en particulier sur tous les cas limites pour ses 3 fonctions principales qui sont la construction, la synchronisation et l'affichage de l'image (ici on entend "autorisation d'affichage").
Conséquences...
Les différences entre ces circuits sont devenues notables lorsqu’ils ont été utilisés au-delà des recommandations et des spécifications, notamment par quelques programmeurs de jeu et les demomakers. Ci-dessous quelques exemples:
Jeu "007 The Living DayLights" sur CRTC 1 à gauche (Le HUD est dupliqué à cause du bug C4=0) et CRTC 0 à droite (affichage correct)
Démo "Madness" sur CRTC 1 à gauche et CRTC 0 à droite
Un code qui fonctionne parfaitement sur une machine peut ne pas fonctionner du tout sur une autre. En général cela se traduit par une perte de synchro de l’image affichée et qui se traduit par une bouillie de pixels défilants. Les différences peuvent également provoquer un blocage du code.
La question s'est alors posée naturellement de comprendre l'origine de ces différences afin d'y remédier pour éviter qu'un programme soit fonctionnel pour seulement une proportion des utilisateurs de la machine. Une fois identifié formellement, chaque circuit (ou groupe de circuits) a été numéroté :
Dans certains cas extrêmes, la compatibilité implique de petits aménagement ou de réécrire une partie du code. Dans d'autres cas, on peut tomber sur des impasses selon la méthode employée et/ou les connaissances du développeur sur les différents circuits. Enfin il appartient bien évidemment au développeur concerné d'adapter (ou non) son code et/ou de réduire la nature de l'effet présenté pour les autres CRTCs.
Dans tous les cas, cela repose en partie sur les connaissances disponibles et/ou sur les recherches qu'on a soi même pu faire pour comprendre le fonctionnement intime des circuits.
Les documentations non officielles...
Quelques demomakers ont rédigé des documentations dans les années 90 pour expliquer les techniques « CRTC » et qui ont servi de base et de référence à de nombreuses personnes par la suite.
Logon System a tenté de vulgariser certaines techniques, comme la "rupture", dans le mensuel "Amstrad Cent pour Cent".
Des documentations plus "confidentielles" (qui ne le sont pas restées longtemps) ont circulé. On peut citer Gozeur (salut Renaud si tu me lis) au début des années 90 et Ramlaid (Salut Thierry si tu me lis) en 1999.
Même si ces documents contenaient quelques erreurs, ils avaient pour mérite d’exister et de décrire quelques grands principes de techniques utilisés dans les démos, comme la « rupture » et ses déclinaisons diverses, qui permettent de vectoriser l’affichage. Malheureusement, ces documents étaient assez pauvres dès qu’il s’agissait d’expliquer pourquoi les circuits se comportaient différemment selon leur programmation. A l'époque il était difficile de disposer à volonté de l'intégralité des configurations et de dénombrer le nombre de CRTCs différents réellement en circulation.
Tout au plus pouvait on trouver quelques avertissements indiquant que telle ou telle valeur était radioactive.
Durant les années qui ont suivi les années 90, assez peu de progrès ont été réalisés sur la connaissance de ces circuits. Une grande partie de la demoscene qui a succédé à la disparition de la micro-informatique après 1993 a principalement vécu sur les acquis de la génération précédente.
On peut cependant noter que le portail réalisé par Grim après les années 2000 a présenté plusieurs travaux d’analyse intéressants sur le GATE ARRAY, un circuit central de l’architecture du CPC créé par Amstrad et qui traite, entre autres choses, de l’affichage des pixels pointés par le CRTC. Les pages sur le CRTC sont restées assez pauvres, se contentant comme d’autres avant, d’étaler dans une table comparative le format des registres issus des guides techniques pour les 5 CRTCs identifiés. Le portail contient d'ailleurs quelques erreurs notables pour définir certains registres ou fonctions des CRTC 0 et 1, et qualifie à tort de « buggés » les modes « interlace » de ces circuits.
Les différences...
Un document présentant les différences réelles entre les CRTCs est resté longtemps une « arlésienne » dans le petit monde du CPC.
La connaissance des « différences » entre les CRTCs a été longtemps résumée à une table famélique véhiculée de fanzine en fanzine, contenant des informations superficielles, incomplètes, parfois inexactes ou carrément fantaisistes :
Amslive 19 page 15 (juillet 2002) / Amslive 18 page 12 (juin 2002)
Portail Quasar (http://quasar.cpcscene.net/doku.php?id=coding:test_crtc#fn__38)
Comme les documentations que j'évoquais dans le paragraphe précédent, ces tables avaient au moins le mérite d'exister, mais elles ressemblaient souvent à des recettes de cuisine assorties de peurs séculaires à base de "bugs", de "bufferisation" et de valeurs interdites. Par exemple, ne jamais mettre 0 dans R0 sur CRTC 0, sinon un suck mode se déclenche! 😏
L’étude des circuits...
A la truelle ?
On peut souvent résumer la logique de fonctionnement de ces circuits en indiquant qu’il s’agit de simples compteurs qui repassent à zéro en atteignant leur limite et déclenchent différents états en atteignant d’autres valeurs.
C'est vrai en grande partie mais les choses ne sont pas toujours aussi simples, sinon ce type d’étude aurait déjà été réalisé et publié depuis longtemps.
Lorsqu’il s’agit de circuits, une méthode d’électronicien consiste à « décaper » brutalement le circuit chimiquement pour obtenir une cartographie de ses transistors à l’aide de photos réalisées via un microscope électronique. Cela a déjà été fait, mais le résultat produit reste indigeste et n'a débouché sur rien à ce jour.
Les approches !
Pour pouvoir étudier la logique de ces circuits et leurs différences, il faut donc comprendre comment chaque circuit gère ses compteurs, ses états internes et ses « déclencheurs », en essayant de deviner comment et pourquoi les ingénieurs ont traité telle ou telle problématique.
C'est un travail de recherche qui nécessite de faire des observations, émettre des hypothèses, établir des expérimentations pour obtenir des résultats, puis interpréter ces résultats pour définir des conclusions.
Je pense qu'un des gros problèmes rencontré par les concepteurs de ces circuits a été l'implémentation et l'intégration des fonctions dite d'"interlace". Ces fonctions promettaient au client de pouvoir améliorer la lisibilité de l'affichage ou de doubler le nombre de lignes (625 lignes) moyennant une baisse de fréquence à 25Hz de l'affichage complet d'une image (avec le risque de décollement de rétine des usagers en "vidéo mode" 😅).
Les ingénieurs ont du trouver un système compatible avec ces fonctions pour les choix techniques réalisés pour la gestion de construction et de synchronisation de l'affichage.
Une approche "software" requière un travail de recherche long, méthodique, parfois fastidieux, et nécessite une certaine rigueur. Il faut réaliser de très nombreux tests pour valider ou infirmer toutes les hypothèses posées, en tenant compte de l’architecture construite autour du circuit. Le résultat d'un test peut lui même amener d'autres hypothèses en cascade. Ce qui nécessite de nouveaux tests, et ainsi de suite...
Méthodologie
Les deux premières choses dont j'ai eu besoin pour aborder cette recherche était d'une part d'éliminer tous les facteurs susceptibles d'influencer les résultats obtenus et d'autre part de générer un code accessible simplement permettant d'étudier des résultats explicites adaptés aux CRTCs testés.
Le premier problème a été réglé en définissant un point de référence fixe indépendant des paramètres du circuit, et en adoptant une méthode de programmation des tests basés sur de la programmation dite "en temps fixe". C'est pourquoi ces méthodes et les outils associés sont documentés dans le Compendium.
Le second problème consistait à créer un module d'expérimentation accessible via un programme unique et contenant les tests pouvant servir de référence visuelle et de base aux hypothèses posées. C'est ce qui a été fait avec le programme SHAKER, qui contient des milliers de tests réalisés sur tous les CRTCs.
Avant que des bases solides soient posées sur certains comportements qui n'avaient jamais été étudiés, la méthode de la vidéo s'est avérée très intéressante pour déterminer plus facilement ce qui se produisait dans certains cas. En effet, dès que la construction de l'écran n'est pas celle qui est attendue par le programme de test, l'écran se désynchronise. Cela démontre que l'hypothèse de base est incorrecte, ou qu'elle est correcte mais qu'un ou plusieurs autres phénomènes interviennent dans l'équation. Il est parfois difficile de savoir ce qui est exactement à l'origine d'un problème de comptage et donc de synchronisation ou d'affichage. L'étude image par image de la vidéo de quelques tests a parfois permis de comprendre ce qui se produisait.
La perte de synchronisation est le phénomène le plus classique que tout demomaker CPC a déjà expérimenté à répétition. Afin de limiter la casse, et notamment lors de l'étude des fonctions interlace, j'ai du mettre au point différents systèmes permettant de forcer la synchronisation.
Un grand classique, qui reste assez empirique, est de gérer un compteur pour "rechercher" une stabilité d'affichage. J'ai du mettre au point d'autres méthodes, dont une que j'ai appelé "l'autosync" et qui permet de synchroniser automatiquement une rupture à partir du second frame.
L'objectif n'est pas ici de lister les différentes méthodes de test, car chaque sujet présente ses propres défis et contraintes. Mais la recherche de ces méthodes est à mon sens ce qui a rendu ce travail si intéressant.
Environnement
Il a également été nécessaire de tenir compte de l'environnement technique du CRTC pour pouvoir l'étudier.
On accède par exemple aux circuits via des instructions Z80A d'entrées/sorties. La prise en compte de ces instructions n'est pas la même en fonction du type de circuit, mais également en fonction de l'instruction utilisée. Il était donc nécessaire d'étudier la logique électronique derrière ces instructions et la décrire le plus simplement possible, ce qui est loin d'être une tâche aisée.
C'est un peu technique, mais il faut imaginer que le Z80A et le CRTC sont cadencés par le GATE ARRAY, que le Z80A ainsi cadencé envoie ses I/O au CRTC ou au GATE ARRAY, que le CRTC indique au GATE ARRAY comment gérer ses interruptions, et que le GATE ARRAY indique au Z80A quand il souhaite obtenir une interruption!
J'en connais qui viennent juste de dire "Un beau bordel !"
Par ailleurs, il ne faut pas oublier que le CRTC n'affiche et ne synchronise rien du tout. C'est un "contrôleur" ! Il indique au GATE ARRAY à quelle adresse mémoire il doit aller lire les octets en ram et à convertir en pixels, quand cesser (ou pas) d'afficher des pixels (le BORDER sur CPC), et quand envoyer les signaux de synchronisation horizontaux et verticaux au moniteur.
Sur ce dernier point, de nombreuses personnes ont écrit que les CRTCs sont "buggés" en mode "interlace". C'est inexact car c'est le GATE ARRAY qui reçoit les deux types de signaux de synchronisation du CRTC, mais qui ne les envoie pas quand il les reçoit. Il s'agissait sans doute pour Amstrad de faire l'économie de gestion de 2 signaux de synchro en les combinant.
Travail collaboratif !
Pour plusieurs tests, j'ai pu faire appel à quelques bonnes âmes (que je remercie encore au passage) pour utiliser certains de mes tests interactifs parfois un peu barbares à paramétrer, et également présents dans SHAKER. En effet, bien que je dispose de la plupart des machines, il s'est avéré que des modèles de GATE ARRAY présentaient des différences qu'il était possible de mettre en évidence, et j'étais loin de disposer de toutes les configurations nécessaires.
Lorsque j'ai été coincé par les limites software en matière de test, j'ai fait l'acquisition, grâce aux conseils de Fred le Fugitif, d'un analyseur numérique qui a été bien pratique pour "voir" la tête des signaux présents sur certaines broches des circuits étudiés. Cela me permet d'affirmer que le signal C-SYNC du GATE ARRAY au moniteur est de type XNOR (à vos souhaits). Il devient en effet difficile, sur une machine dont la plus "rapide" des instructions correspond à 1 µsec, de détecter avec un test software des phénomènes qui ont lieu sur une échelle de 0.0625 µsec.
L'émulation en question...
Enfin, j'ai cherché assez vite à travailler avec un auteur d'émulateur car je pensais que c'était le meilleur moyen de valider ou d'étudier certains comportements des circuits. Ma première tentative fut malheureusement un échec. Tant pis !
J'ai alors eu la chance de découvrir sur un forum les pérégrinations de David MANUEL (DManu78) qui réalisait son émulateur Amspirit en partageant son parcours. Malgré le travail énorme et patient qu'il avait déjà réalisé sur les circuits vidéos, il a accepté de casser et revoir une partie de sa logique initiale pour suivre celle du Compendium (mais le bougre n'a pas lâché le morceau facilement, vous pouvez me croire!).
Nous avons ainsi pu travailler ensemble pour avancer dans la compréhension des mécanismes et bugs présents dans les différents CRTCs et GATE ARRAY.
Si Amspirit contient du Compendium, l'inverse est également vrai.
Amspirit est actuellement l'émulateur le plus fiable et précis pour émuler des composants majeurs du CPC, comme le Z80A, le GATE ARRAY et toutes les versions de CRTCs.
Le résultat de cette émulation démontre ainsi l'exploitabilité et la fiabilité des informations présentes dans le Compendium.
Proof of concept!
Le preuve de concept permet de valider un principe en démontrant sa faisabilité.
Contributeurs aux projets Wikimedia
SHAKER est en soi une réalisation qui a pour vocation de démontrer l'ensemble des concepts et informations décrites dans le Compendium.
On peut y trouver quelques mises en application de techniques décrites dans le document, comme celle de la rupture ligne à ligne sur CRTC 2 ou encore le scrolling vertical au 1/128ème de pixel.
SHAKER 2.5 module B, test 0 : Scrolling Sub Pixel
Dans certains cas, les techniques décrites ont été démontrées dans des POC plus colorés ajoutés sur le disque ADD-ON accompagnant SHAKER. Cela a notamment été le cas pour l'application des ruptures RVLL, pour les travaux relatifs aux HSYNC et qui permettent d'obtenir des scroll fluides au pixel mode 1 et 2 sur CPC. C'est également le cas de la petite démo DSC#4 qui a semble-t-il irrité quelques personnes.
Disque Shaker Addon - Scrolling Horizontal Mode 1 au pixel
Structure du Compendium!
Documents officiels
Comme je l'évoquais précédemment, les guides constructeur officiels sont pratiquement tous structurés de la même façon. Les fonctions générales du circuit sont décrites succinctement sur la première page, avec le nom des différentes broches du composant, leurs tolérances, périodes et descriptifs sommaires.
Quelques diagrammes parallélisent les états haut/bas des différentes broches sur des périodes d'affichage données, mais sont assez incompréhensibles pour une personne sans bagage électronique.
Un schéma décrit sommairement l’interaction entre les compteurs et les registres avec l'emplacement des "comparateurs" internes. Une table, qu'on retrouve sur beaucoup de portails et fanzines, décrit la résolution et donne une description sommaire et générale du rôle de chaque registre.
Chaque registre est décrit dans l’ordre.
C’est paradoxal mais c'est souvent sur les fonctions "interlace" que ces documents sont les plus prolixes. Cela ne les rend pas moins incomplets car cela se résume en général à 1 ou 2 pages maximum qui ne permettent pas de comprendre comment de nombreux problèmes ont été traités. De manière générale dans ces documents, les descriptions sont imprécises, ambigües, incomplètes voir erronées.
Démarche
J'ai du réfléchir au moyen de présenter les conclusions de mes recherches.
Il était nécessaire de structurer un document présentant une approche très précise du comportement de chaque circuit, en offrant une description comparative dans un contexte d'architecture spécifique.
Ma première approche a été de structurer un document à partir des 3 grandes fonctions gérées par les CRTCs. Je rappelle ici qu'il s'agit de la "construction", de la "synchronisation" et de "l'autorisation d'affichage (border)".
Cette approche semblait à priori la plus pertinente car elle permettait de regrouper des compteurs et registres par fonction.
Par exemple, la construction d'une image regroupe un compteur C0 associé au registre R0, le compteur C9 associé au registre R9, le compteur C4 associé au registre R4, le compteur C5 ou C9 au registre R5, et enfin les registres R12/R13 à une variable interne (VMA).
Mais la description détaillée de ces différents compteurs et registres a rapidement posé des problèmes de lisibilité, et notamment lorsqu'il s'est avéré que des registres ont "le cul entre deux chaises". A moindre échelle, c'est par exemple le cas de R1, qui participe à la gestion du BORDER, mais qui est également impliqué plus ou moins étroitement dans la gestion du traitement de l'adresse vidéo. Ou bien encore lorsque des mécanismes de traitement spécifique de certaines fonctions diffèrent selon les logiques de synchronisation. Et les choses ne se sont pas du tout arrangées avec les fonctions "interlace".
Une autre solution consistait à reprendre la logique des guides constructeurs et détailler les registres dans leur ordre numérique puisque les concepteurs avaient tous abordé la question de cette façon. Cette approche a également montré ses limites dans la perspective d'aborder la logique des comparateurs établie par les concepteurs. Dans une logique fonctionnelle de "poupée russe", les fonctions de constructions d'une image sont hiérarchisées. Des "mots" composent une ligne (R0), les lignes qui composent un "caractère" (R9), et les "caractères" composent un frame (R4). Tant qu'on ne sort pas de la logique d'affichage "standard", les décrire dans cet ordre ne présente aucun problème. Les choses se compliquent nettement si on entre dans la logique d’enchaînement de ces compteurs et qu'on peut regrouper dans un seul "mot CRTC" les concepts de ligne et de frame.
Si par exemple on souhaite décrire ce qui se produit avec R0=0 en ayant mis R4=0, R9=0, il vaut mieux avoir expliqué à quoi correspondent R4 et R9 avant d'aborder R0, et à plus forte raison si on donne des exemples concrets et schématiques de techniques vidéos comme les ruptures.
Cela m'a donc amené à remanier l'organisation du document jusqu'à adopter l'approche qui me semblait la meilleure, et accessoirement la faire valider par un de mes amis chercheur scientifique.
Solution
La solution qui m'a semblé la plus viable était de décrire les registres individuellement, en les regroupant par fonction, et ordonnés dans l'ordre le plus logique pour éviter d'aborder des sujets nécessitant trop de renvois sur des concepts pas encore abordés.
Les fonctions regroupant ces registres sont elle-mêmes ordonnées avec ce même soucis. On "construit" (1) un écran, qu'on peut ensuite "synchroniser" (2) et sur lequel on tient compte des zones d'affichage (3) et de gestion du pointeur vidéo (4).
L'intégration de cas pratiques, associé à de nombreux schémas, a permis je pense de faciliter la compréhension des chapitres les plus complexes.
C'est une approche qui peut déconcerter des personnes qui ne liraient pas les chapitres les plus complexes du document dans l'ordre pour appréhender préalablement l'ensemble des concepts et définitions. Une personne trop sûre de ses acquis qui irait directement sur un chapitre technique sans passer par les définitions des concepts et états pourrait patauger dans la semoule malgré la présence de nombreux schémas.
Le document a été soumis à plusieurs relecteurs qui ne m'ont pas fait de retour critique.
Le document adopte la structure générale suivante :
- Généralités / Terminologie / Sigles (chapitres 1, 2, 3)
- Le CRTC sur le CPC, son accès, et les autres circuits du CPC (chapitres 4, 5)
- Principes
- Les principes de construction, synchro, affichage d'une image (chapitre 6)
- Les principes de synchronisation de l'étude (chapitre 7)
- Les principes de conversion de la mémoire en pixel en interaction avec la Z80A (chapitre 8)
- L'affichage des pixels et la gestion des modes graphiques par le GATE ARRAY (chapitre 9)
- Fonction comptage (construction):
- Registre R9 (généralités, délais, règles par CRTC) (chapitre 10)
- Registre R5 (généralités, ajustement & intéractions, RFD) (chapitre 11)
- Registre R4 (généralités, RLAL crtc 0 & 2) (chapitre 12)
- Registre R0 (généralités, règles par CRTC, RVLL, RVI, mises à jour, cas particuliers) (chapitre 13)
- Fonction synchronisation :
- Registre R3 (généralités, vsync, hsync, mises à jour, interruptions) (chapitre 14)
- Registre R2 (généralités, hsync, vsync, affichages)(chapitre 15)
- Registre R7 (généralités, csync et vsync, conditions, mécanismes de protection et de retard) (chapitre 16)
- Fonction affichage :
- Registre R1 (généralités, règles, gestion vma/vma') (chapitre 17)
- Registre R6 (généralités, règles et conflits par crtc) (chapitre 18)
- Registre R8 (généralités, fonctions skewdisp, interlace (modes, programmation, parité, ligne additionnelle, mid vsync, comptages par crtc) (chapitre 19)
- Pointeur vidéo : Registres R12/R13 (généralités, calcul, mises à jour par crtc, délais) (chapitre 20)
- Registres en lecture. Généralités, status (chapitre 21)
- Fullscreen & centrage (chapitre 22)
- Développement:
- Trucs et astuces (mise à jour R12/R13, usage commun registres, attente vsync, valeur 0, ....) (chapitre 23)
- Temps fixe (introduction, méthodes, interruptions, outils, méthode, ...) (chapitre 24)
- Durée des instructions en Z80A sur CPC (chapitre 25)
- Interruptions (généralités, compteur r52, déclenchement, modes, crtc et interruptions)(chapitre 26)
- Identification des CRTC (chapitre 27)
Je pense avoir terminé ce petit tour d'horizon de la conception de ce document.
Je suis reconnaissant envers les personnes qui m'ont apporté des informations et m'ont fait des retours constructifs, que ce soit sur des petites coquilles d'orthographe ou techniques, et ce afin d'améliorer le document. Comme je l'indique dans le préambule, "la vérité tient peu de place, mais l'erreur occupe une infinité de lieux.".
En attendant, je vous invite à recharger la version française de la version 1.7, qui avait un problème au niveau du sommaire. Je viens également de corriger une erreur qui ma été signalée dans le chapitre 4.4.4.
https://shaker.logonsystem.eu/ACCC1.7-FR.pdf
La version 1.8 avec le "Meow Bug" du CRTC 2 attendra encore un peu...
Longshot / Logon System