★ CODING ★ AMSLIVE ★ AMSLIVE n°16 - CRTC ( DETECTION ) ★ |
AMSLIVE n°16 - CRTC Detection | AMSLIVE n°18 - Crtc Detection | AMSLIVE n°19 - Crtc Detection - Retour Au Source |
Lors des premiers AMSLIVE, j'avais entamé une initiation CRTC. Mais nombres de petits scarabés n'étaient pas encore prêts. Aujourd'hui au contraire, on ressent la volonté de la plupart des CPCistes de comprendre exactement comment marche leur machine, et c'est une bonne chose. Miam.On va réattaquer par la détection du type de CRTC en passant en revue quelques différences qui interviennent, registre par registre. LE REPERAGE VISUEL Premièrement, si votre CPC est blanc cassé, il y a de grandes chances que ce soit un CPC+, dont le CRTC émulé est désigné comme étant un type 3. Il semble que le type 4 se comporte de la même façon, ce qui est plutôt logique puisqu'il s'agissait d'unpré-ASIC destiné à vérifier la fiabilité de l'émulation. Je m'exprime vraiment l'importe comment. (NDSNN : Oui.) D'autre part il devrait y avoir dans ATM 5 une table de correspondance entre le "numéro de série étiqueté au dos de votre CPC et le type de CRTC. REGISTRE 1 Quand R1>R0, il ne doit pas y avoir de border. Pourquoi, élève Tigrou ? - Parce que le border est généré quand le compteur x (ou C0) atteint R1. Or C0 restant compris entre 0 et R0 inclus, il ne peut donc égaler R1, tout comme la grenouille ne peut égaler le bœuf. Pourtant, sur types 0 et 2, on obtient quand même une bande d'un demi-octet de large de border, qu'on mettra sur le compte d'un cafouillage interne. Ainsi, la part de la Dream end démo présentant 2 écrans symétriques collés côte à côte ne serait pas faisable telle quelle sur un type autre que 1. Mais elle serait faisable beaucoup plus facilement d'une autre façon ! Le phénomène n'est pas exploitable pour une auto-détection, mais offre un test rapide sous basic : SPEED INK 11,12:BORDER 3,25:OUT &BC00,1:OUT &BD00,64 donnera donc une bande verticale de border sur les type 0 et 2. REGISTRE 2 Sur type 2, quand R2 + R3 = R0 + 1, il n'y a plus de VBL générée, et quand R2 + R3 > R0 + 1, on se retrouve avec du border partout. Sur type 0 et 1, dans la même configuration (R2 + R3 = R0 + 1 ) l'écran se décale d'une ligne vers le bas. Sur type 3, c'est quand R2 + R3 = R0. Nous verrons après ma prochain mutation comment exploiter cette particularité. REGISTRE 3 On vient de parler du registre 3 juste à l'instant, vous vous rappelez ? En fait je mentionnais seulement le quartet de poids faible de ce registre, qui détermine la "largeur" du hsync. Normalement, le quartet fort définit par analogie la "hauteur" du */sync, en lignes raster. Mais ça ne marche sur CRTC 0, 2 ou sur le plus, avec lequel l'affectation R3 REGISTRE 6 Sur CRTC 0, mettre le registre 6 à 0 provoque une ligne de pointillés que l'on discerne en changeant la couleur du border. Ca n'amuse personne. (NDSNN : Non.) REGISTRE 8 Beaucoup à dire sur celui-ci. Les bits 0 et 1 déterminent le mode de balayage. Quand ils sont tous deux à un, on bascule en mode entrelacé. Sur type 2, aucun problème (les données se trouvent juste affichées en double car l'entralecé nécessite deux fois plus de mémoire vidéo). Sur type 1, on a deux écrans et une grosse VBL au milieu : le CRTC ne corrige pas le nombre de ligne total à afficher, qui aurait dû se voir doublé (parce qu'il n'y a qu'une ligne sur deux de balayée). Sur type 0, pareil, mais en pire : l'écran n'est plus à 50 hz, car il y a un bloc de trop (petit bug du registre 9 déjà explicité dans ces pages). Le port &BExx donne en théorie accès à un registre d'état. Attention à ne pas envoyer de OUT dessus, sinon on sera pas copains. Sur CRTC 0, rien ne sort, et on lira &FF. Sur CRTC 1, le bit 6 est forcé à 1, les autres à 0 sauf le bit 5 qui a une signification assez rigolote : il passe à 1 quand C4 atteint R6, c'est à dire quand le border commence à être affiché (verticalement parlant). Sur CRTC 2, on a &FF. Sur CRTC 3, il joue le même rôle que &BFxx. Sur CRTC 1 : On obtient 0 tout le temps. Pas de lecture ! Sur CRTC 2 : Idem. Ce type a vraiment hérité de toutes les tares ! Sur CRTC 3 : Idem que CRTC 0, sauf que le registre sélectionné via &BCxx est alors décodé sur 3 bits seulement, ce qui veut dire que l'offset peut aussi être lu via R4 & R5 ou R20 & R21, par exemple. En lisant les registres R2 & R3 (ou R10 & R11, ...) sur le PLUS, on obtient des bits d'état plus loufoques les uns que les autres. Par exemple, le bit 7 du R3 indique le premier bloc d'une ligne de caractère (ce "flag" se retrouve sur d'autres bits). D'autres bits passent à 1 une fois toutes les 32 lignes. Tenant à ma santé mentale précaire, je n'ai pas fait de tests plus poussés. Mais sachez que certains bits s'animent seulement une fois l'ASIC délocké (je me suis fait avoir après une petite partie de Burnin' Rubber !). DEMANDEZ LE PROGRAMME Un test basé sur la lecture de &BExx donne une et une seule des informations suivantes : La lecture de &BFxx permet de départager le 0 et le 2. Et on déterminera le type 3 par une détection du PLUS. On va créer un octet dont le bit 0 correspondra au type 0, le bit 1 au type 1, .... et le bit 5 à un émulateur. Chaque test positionnera à 1 les bits correspondants aux CRTC éliminés. A la fin, on doit simplement obtenir un seul bit à 0. Attention si vous lancez le test sous BASIC, l'écran risque de se retrouver sans dessus-dessous (à cause du changement d'offset). Attention bis, les émulateurs ne se verront pas forcément détectés. Dans ce cas, on pourra aisément ajouter de nouveaux modules de test. ; |
Page précédente : AMSLIVE n°15 - YM FAIT DU SKI |
|