CODINGAMSLIVE ★ AMSLIVE n°16 - CRTC ( DETECTION ) ★

AMSLIVE n°16 - CRTC DetectionAMSLIVE n°18 - Crtc DetectionAMSLIVE 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.
Dans un premier temps j'indiquerai quelques opérations manuelles, puis on verra comment les appliquer pour une autodétection.

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.
Nul besoin d'assembleur pour l'instant, vous pouvez effectuer tous les tests sous BASIC.

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.
Comme R0 vaut par défaut 63 et R3 = 14, alors un OUT &BC00,2:OUT &BD00,50 décrochera l'écran. Pour contourner ce problème, on fixera R3 à 13.

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).
Les bits 4 et 5 permettent de "décaler le border" ou carrément d'en afficher partout (s'ils sont tous les deux à 1, le R8 LES REGISTRES EN SORTIE
OU QUAND LE CRTC VA A LA PLAGE

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.
Justement, &BFxx (pas de OUT non plus ! Gare !) propose de lire un registre sélectionné par &BCxx. Mais seuls RI 4 & R15 (crayon optique, non testé) ainsi que R12 & RI 3 (offset) sont en lecture. Sur CRTC 0 : R12 & R13 répondent bien, si un autre registre est sélectionné, on obtient 0.

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 :
— c'est un type 1.
— c'est un type 0 ou 2.
— c'est un type 3 ou 4.
— c'est un autre type (émulateur ou CPC exotique) !

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.

;
; Détection CRTC. Madram pour
; AMSTRAD LIVE. 05/2000
;
ORG #A000
;
CALL TEST1
CALL TEST2
CALL TEST3
;
; un test de moins ne permettrait pas de
; conclure
;
CALL CONCLUT
OR #30 ; Conversion chiffre ->
; code ASCII
JP #BB5A

TEST1
;
; Idée communiquée par Candy. Pas très
; rigoureux :) mais ça marche
;
LD BC,#7F54 ; Je ne précise
; pas le stylo,
; peu importe.
OUT (C),C
IN A,(C) ; En réalité on
; ne lit rien
CP C ; Mon instruction
; préférée
LD B,%011111 ; Type emulateur
JR Z,SET_BITS ; De mauvais
; émulateurs autorisent la lecture du GA
INC A ; Si 255 -> CPC normal
LD B,%001000 ; Tout CPC sauf +
JR Z,SET_BITS
LD B,%110111 ; CPC PLUS
JR SET_BITS
;
;
TEST2
;
; On lit port #BExx
;
LD BC,#BC0C ; On s'assure de
; l'offset (du poids
; fort du moins)
OUT (C),C ; car le CPC + renverra
; cette valeur.
LD BC,#BD30
OUT (C),C
INC B
IN A,(C)
CP C
LD B,%100111 ; CPC PLUS ou type 4
JR Z,SET_BITS
INC A ; #ff?
LD B,%111010 ; Si oui->CRTC 0 ou 2
JR Z,SET_BITS
AND #df ; On écarte le bit 6 qui
; peut varier,
CP #41 ; et on doit obtenir #40
; sur CRTC 1
LD B,%111101
JR Z,SET_BITS
LD B,%011111
JR SET_BITS
;
;
TEST3
;
;On lit le port #BFxx
;
LD BC,#BC0C ; On s'assure de l'offset
OUT (C),C ; Je sais, on l'a déjà fait,
; mais c'est plus propre :
LD BC,#BD30 ; les tests sont
; ainsi autonomes
OUT (C),C ; ,
SET 1,B ; Spéciale décicace à Shap
IN A,(C)
CP C ; Si on relit la valeur ->
; CRTC 0, 3, ou 4
LD B,%100110
JR Z,SET_BITS
OR A ; Si 0 -> CRTC 1 ou 2
LD B,%111001
JR Z,SET_BITS
LD B,%011111 ; C'est pas un CPC
; normal !
JR SET_BITS
;
;
;
SET_BITS
;Mise à 1 des bits -> c'est un OR !
LD A, (CRTC)
OR B
LD (CRTC),A
RET
;
;
CONCLUT
;
; En sortie, A contient le type (5 pour un émulateur)
;
LD A,(CRTC)
LD BC,#500 ; B compteur, C
; numéro du type
;
CON_LP
RRA
JR NC,CON_LP2
INC C
DJNZ CON_LP
;
; Les 5 premiers bits sont à 1. Peu importe si
; le dernier est à 1 ou pas :
; dans les 2 cas on a affaire à un émulateur
;
LD A,C
RET
CON_LP2 ; On vérifie qu'il n'y a pas d'autre
; bit à 0
RRA
JR NC,CON_NOK
DJNZ CON_LP2
LD A,C
RET
;
CON_NOK LD A, 5
RET
;
;
CRTC DEFB 0
RET
;
;
CRTC DEFB 0
LP2
LD A,C
RET
;
CON_NOK

Signé : Modrom , AMSLIVE n°16

★ ANNÉE: 2000
★ AUTEUR: MADRAM

Page précédente : AMSLIVE n°15 - YM FAIT DU SKI
★ AMSTRAD CPC ★ DOWNLOAD ★

Other platform tool:
» coding  amslive16-CRTC  detection    LISTINGDATE: 2012-08-27
DL: 555 fois
TYPE: text
SIZE: 4Ko

★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser...

Lien(s):
» Coding » Wacci CRTC (2/2)
» Coding » AMSLIVE n°18 - BIDULES ET MACHINS VRAIMENT CHOUETTES
» Coding » AMSLIVE n°12 - Sons et Samples
» Coding » AMSLIVE n°02 - Balayage Video
» Coding Src's » Detect CRTC type by Rhino
» Coding » Menu - CRTC
Je participe au site:

» Vous avez des infos personnel ?
» Vous avez remarqué une erreur dans ce texte ?
» Aidez-nous à améliorer cette page : en nous contactant via le forum ou par email.

CPCrulez[Content Management System] v8.7-desktop/c
Page créée en 811 millisecondes et consultée 2330 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.