CODINGAMSLIVE ★ AMSLIVE n°20 - LES MAÎTRES DU TEMPS ★

AMSLIVE n°20 - les Maître du TempsCoding Amslive

Si vous en avez assez de tâtonner pour chaque nouveau split-raster à programmer, ce qui suit peut vous intéresser. Dans une certaine mesure, cet article fait suite à celui sur la synchro (numéro 4 page 3).

BONNE POSITION HORIZONTALE

Nous allons voir dans ce paragraphe que la position d'un split-raster se détermine très aisément.

Imaginez deux secondes (100 trames, si vous préférez) un OUT (que ce soit sur le port BC ou An) exécuté juste après un HALT (c'est pas fini ces parenthèses ? Le hachage, légitime en cuisine, rend toute lecture indigeste), la routine d'interruption en #38 se résumant à un classique EI : RET.
S'il s'agit d'un changement de couleur, celui-ci se produira quand C0=7 (cf. schéma 1), en supposant que R2 et R3 soient chargés à leurs valeurs par défaut (&2E et &8E respectivement).

En effet, la HSYNC du CRTC sert de compteur au VGA et par suite de déclencheur pour les interruptions. Chose amusante (prompte à dérider n'importe quel mormon dépressif), c'est la fin du HSYNC qui est déterminante, d'où l'immixtion de R3 dans l'affaire.

Le délai entre la fin du HSYNC et l'action du OUT comprend le traitement de l'interruption (RST #38) et du EI : RET. En configuration IM 2, cela prend 2 NOPs de plus.

Revenons à nos buffles. Relativement au début d'un mot (les abscisses multiples de 16 sous BASIC ou OCP), le changement de palette intervient sur :

  • le pixel 9 (soit un octet et un pixel après, gloup î) en mode 2.
  • le pixel 4 (soit exactement un octet après) en mode 1.
  • le pixel 2 (soit exactement un octet après) en mode 0.

Aussi, visuellement, une bande de couleur débutera un poil plus à droite en mode 2 qu'avec les autres modes.

Bien entendu, une modification CRTC ne se produit qu'au début d'un mot. Par conséquent, toujours avec notre OUT précédé d'un HALT, mais dans le cadre d'une sélection de border (cadre / border -> humour), ce dernier ne débutera qu'au mot suivant, quand C0=8.

Rien de plus cohérent à ce que le VGA, cadencé à 16 MHz, prenne un changement en compte plus rapidement que le CRTC cadencé à 1 MHz.
Il apparaît donc impossible, à priori, d'aligner verticalement un « split-raster » et un « split-border ». Ce n'est pas Targhan qui me contredira.
Pour être complet, signalons l'existence de phénomènes rares et bizarres, apparemment liés à la connexion d'interfaces : changement de couleur à la moitié d'un pixel, apparition d'une troisième couleur à la frontière de split-raster, ou encore menues fluctuations sur cette frontière.

CPC+ ATTARDÉ

Sur AMSTRAD+. les rasters se voient, décalés d'un mot vers la droite (en fait, 3/4 de mot, voir plus bas). On corrige cela grossièrement en jouant sur les tempos, ou en décrémentant R3 (il a été indiqué plus haut que le VGA se basait sur la fin du HSYNC. Les synchronisations reposant généralement sur un HALT, le tour est joué).

Cependant, si les split-rasters doivent finement coller aux graphs, cette correction ne convient pas. En effet, sur PLUS, le changement de palette intervient par rapport au début du mot :

  • au pixel 5 en mode 2.
  • au pixel 2 en mode 1.
  • au pixel 1 en mode 0.

C'est un demi-octet plus tôt que sur CPC. On s'en remet alors au registre ASIC de retard vidéo.
En revanche, et le délire emporte ici l'assemblée : l'effet d'un OUT pareillement temporisé, mais concernant cette fois le CRTC, se produit lui 3 NOPs plus tard (le temps que l'A SIC accuse réception, sûrement...) !

Je propose d'arrêter de nous prendre la tête sur cette machine déviante, afin de reprendre sereinement un exposé dont la cohérence n'échappera à personne.

HALT HIER, PRISE DE MAIN

Plaçons nous maintenant dans le cas d'une routine de raster sous interruption.
Les interruptions intervenant après l'instruction en cours, la routine peut être retardée de quelques microsecondes ; 6 |µs au maximum, puisque les instructions les plus longues nécessitent 7 µs (il s'agit de RR ( IX+d ) et consorts, avec ou sans auto-copie dans les registres). Les instructions auto-bouclantes (LDIR, etc.) sont interrompues avant de reboucler sur elles-mêmes, justement.
Or donc, le raster sera très probablement « instable ». Si on souhaite simplement modifier une encre à chaque ligne, il suffit de le faire pendant la HBL, assez longue pour couvrir la marge de flottement.
S'il s'agit de changer de mode, on veillera au contraire à ce que cela se produise hors HBL, car c'est à ce moment que le VGA tient compte du mode sélectionné. Je n'ai rien à ajouter.

ÉCRAN VISIBLE

Les limites du balayage observable varient suivant l'écran ' (grand débat de la SYSTEM PARTY). D'ailleurs, certains programmes proposent un recentrage de l'écran, à l'instar de la démo GENESIS de Tom&Jerry ou des jeux d'Elmsoft !
Mais cela reste inutile (sauf peut-être pour une adaptation sur des moniteurs non-AMSTRAD, et encore...) puisqu'il est possible d'homogénéiser le parc de CPCs ! Voici ce que je vous propose :

1 - Charger une démo plein écran telle que THE MEGA SINUS SCROLLY de FRED CRAZY.

Ou, sous BASIC (que le CPC est convivial !) :

BORDER 7,23: OUT &BC00,1
OUT &BD00,48:OUT &BC00,3
OUT &BD00,&8D: OUT &BC00,2
OUT &BD00,50: LOCATE 1,13
?"XX": LOCATE 7,14:?"XX"

Note : R1 à 48 et R2 à 50 sont des valeurs unanimement utilisées par les démomakers. Longshot choisissait quant à lui R1 = 50 et R2 = 51, chiffres préconisés de nos jours par Beb Doglush. Outre une grande largeur d'esprit (ou de tube cathodique), cela dénote un soin particulier apporté aux détails.
R3 à &8D sert aux CRTC 2, et ne gêne pas les autres.

2 - Centrer l'écran grâce à un petit tournevis ! Il y a un accès au potentiomètre H-HOLD à coté du V-HOLD, derrière le moniteur.

Accessoirement, signalons que ce même potard permet le visionnage de quelques démos en manque de temps machine ou mal synchronisées (sacré Antoine ! coucou Chany !).

THE FULL MONTY

Une autre démarche complète celle-ci : une production FULL-SCREEN se doit de recouvrir la totalité de la zone balayée, à destination des écrans plus grands ou justement mal centrés. On évite alors les surprises. À ce propos et soit dit en passant, obtenir des saletés au bord des scrolls hard trahit simplement une mauvaise gestion du trio « balayage, décalage offset et affichage des bandelettes ».
On contrôle le résultat en excentrant logiciellement l'écran, à coup de registres 2 ou 7.
Il me reste à préciser quelle est la zone maximale balayée.

En horizontal :

  • Une ligne CRTC dure 64 us et la HBL 14. La largeur potentiellement visible est donc de 50 mots (R1 - 50).

En vertical :

  • La VBL commence 2 lignes après le passage C4 - R7, et dure 26 lignes. En pratique, on n'aperçoit généralement que les 2 dernières lignes élémentaires de la 4e ligne de caractère.

D'autre part, la ligne de caractère précédant la VBL (en bas de l'écran) n'émerge pas. Ainsi, R6 = 35 et R7 = 36 assure une couverture totale.
Encore une fois, si vous ne voulez pas vous casser le cou - j'hésitais entre cul et couilles -à dessiner quelques bricoles qui ne se dévoileront pas à tout le monde, veuillez au moins placer du border - ou équivalent (RAZ des encres). Si vous ne le faites pas pour vous, faites le pour Beb.

Par exemple, un overflow flagrant du registre 9 au début de l'écran est à notre époque intolérable et sera puni d'une dissection à vif.

LE SALUT APPROCHE

La prochaine fois, nous décortiquerons le fonctionnement du compteur d'interruption du VGA. Pourquoi, comment, il s'en faut de peu.
Roger 2.
MAIS DE QUOI DONC
EST-IL QUESTION , A LA FIN

De nombreuses routines demandent une exécution très précisément localisés dans le temps. On pense aux animations graphiques qui doivent rester en phase avec le balayage écran, mais c'est aussi vrai des effets sonores, de la communication avec un lecteur de disquette ou de l'envoi de données sur un réseau.

Tout au long du texte, on recourt tacitement a la correspondance entre coordonnée temporelle et position à l'écran (à chaque microseconde, 1 mot , soit 16 pixels en mode 2, est parcouru).

Cet article présente observation sur la synchronisation horizontale avant de discuter l'étendue de la surface écran réellement visible. Les deux sujets n'ont rien à voir, mais quasiment personne ne l'a remarqué.

2. Et moi ? (Note de Michael Moore)
1. Fait plus étonnant, elles dépendent aussi de la luminosité de l'image.

AMSLIVE n°20

★ ANNÉE: ???
★ AUTEUR: MADRAM

Page précédente : AMSLIVE n°20 - Crtc Bien Digerer
★ AMSTRAD CPC ★ DOWNLOAD ★

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

» coding  amslive19-CRTC  detection-retour  au  source    LISTINGDATE: 2012-08-27
DL: 332 fois
TYPE: text
SIZE: 5Ko

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

Lien(s):
» Coding » AMSLIVE n°05 - Multiplication de Solutions
» Coding » AMSLIVE n°15 - la Vie en 16
» Coding » AMSLIVE n°03 - Creation Sonore
» Coding » AMSLIVE n°20 - Crtc Bien Digerer
» Coding » AMSLIVE n°10 - Memoire du CPC 2
» Coding » AMSLIVE n°01 - Rasters
Je participe au site:

» Vous avez des infos personnel, des fichiers que nous ne possédons pas concernent ce programme ?
» 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 691 millisecondes et consultée 2127 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.