Minor fixes

Author: pelrun

Ramlaid/ramlaid.md

@@ -148,15 +148,14 @@ Nous allons ici parler des registres 4, 5, 6, 7, 8 et 9. Mais d'abord, sachez qu
 Vous me direz, pourquoi une organisation aussi tordue ? Pourquoi ne pas avoir pris comme point de départ le haut du moniteur ??7 Et bien, c’est simple c'est comme ça que marche le CRTC, il n’a pas de notion du haut ou du bas du moniteur, c’est le moniteur (récupérant une Vsync) qui positionne ce qu'il reçoit du CRTC.
 
 Alors récapitulons tout ça... Prenons l'exemple d’un écran normal (comme sur le schéma), lors du démarrage du CPC. Lorsque l'écran visible commence à être généré, le compteur d'offset est initialisé à la valeur des registre 12 et 13, c’est à dire qu'il pointe sur les 2 premiers octets en #C000, le compteur de ligne de caractère, ainsi que le compteur de bloc sont à 0.
-Le CRTC affiche alors la ligne #C000-#C04F (bloc 0), ensuite le compteur de bloc s'incrémente d’un et on affiche le bloc suivant, à savoir la ligne #C800-#C84F, et ainsi de suite jusqu'au bloc a
+Le CRTC affiche alors la ligne #C000-#C04F (bloc 0), ensuite le compteur de bloc s'incrémente d’un et on affiche le bloc suivant, à savoir la ligne #C800-#C84F, et ainsi de suite jusqu'au bloc 7.
 Au bloc 7, on boucle sur le bloc 0, et ce parce que la valeur du registre 9 (donnant la borne supérieure du compteur de bloc (=> nb blocs — 1) a été atteinte. Puisqu'on revient sur un bloc 0, alors le CRTC sait qu’on change de ligne de caractère, donc il incrémente le compteur de ligne de ‘caractère d’un. C'est à ce moment que le CRTC met à jour le compteur d'offset en additionnant la largeur de l'écran, donc la ligne suivante est #C050-#C09F. Et ainsi de suite pour le compteur d’offset et le compteur de bloc.
-Lorsque le compteur de ligne de caractère arrive à la valeur du registre 6 (25 en standard), le CRTC arrête d'afficher de la mémoire et affiche maintenant du border. Donc notre écran visible fait bien 25*8=200 lignes de haut, ce qui est la hauteur standard.
-Puis, lorsque le compteur de ligne de caractère arrive à la valeur du registre 7 (30 en standard), le CRTC va générer une Vsync, qui va permettre de positionner l’écran sur le moniteur, À noter que
 
-la valeur du registre 7 ne correspond pas à la position de l'écran sur le moniteur, mais à l'endroit où est généré la Vsync par rapport au début de l'écran, ce qui influence bien sur la position de l'écran, c'est une erreur que beaucoup de personne faisait avant (moi compris), et je penses que vous verrez la différence, d’ailleurs, beaucoup de chose s'explique à partir de cela dans le reste de ce cours.
+Lorsque le compteur de ligne de caractère arrive à la valeur du registre 6 (25 en standard), le CRTC arrête d'afficher de la mémoire et affiche maintenant du border. Donc notre écran visible fait bien 25*8=200 lignes de haut, ce qui est la hauteur standard.
+Puis, lorsque le compteur de ligne de caractère arrive à la valeur du registre 7 (30 en standard), le CRTC va générer une Vsync, qui va permettre de positionner l’écran sur le moniteur, À noter que la valeur du registre 7 ne correspond pas à la position de l'écran sur le moniteur, mais à l'endroit où est généré la Vsync par rapport au début de l'écran, ce qui influence bien sur la position de l'écran, c'est une erreur que beaucoup de personne faisait avant (moi compris), et je penses que vous verrez la différence, d’ailleurs, beaucoup de chose s'explique à partir de cela dans le reste de ce cours.
 Enfin, lorsque le compteur de ligne de caractère arrive à la valeur du registre 4 (borne supérieur du compteur de ligne de caractère), le CRTC recommence un nouvel écran. I réinitialise Le compteur d'offset à la valeur des registres 12 et 13, remet le compteur de ligne de caractère et de bloc à 0.
 
-Quelques petits calcul s'impose. Le CRTC affiche donc 200 lignes d'écran visible, ensuite il affiche 5*8 lignes de border (en effet, reg 1-25 et reg 7=30), puis il génère une Vsync (qui fait à peu près 16 lignes), et affiche le reste de border, de 8*8 lignes en tout (reg 4=38, reg 7-30). Notez également que la Vsync est générée en même temps que le border, donc la Vsync est comprise dans les 8*8 lignes de border suivante, Tant que j'y suis sur les lignes, je vous fait remarquer qu'en tout, et en standard le CRTC affiche 312 lignes. En effet, il affiche 39 lignes physique (on peut les appeler comme ça (reg 4=38, et on démarre à 0)) de 8 lignes de haut (reg 9+1), soit 312 lignes. Sachant qu'une ligne fait 64 NOPs, alors un écran est fait en 19968 NOPs. Un NOP=1 microseconde, donc un écran est balayé en 0.019968 seconde. Combien d'écran balayé en 1 seconde ?
+Quelques petits calcul s'impose. Le CRTC affiche donc 200 lignes d'écran visible, ensuite il affiche 5x8 lignes de border (en effet, reg 1-25 et reg 7=30), puis il génère une Vsync (qui fait à peu près 16 lignes), et affiche le reste de border, de 8x8 lignes en tout (reg 4=38, reg 7-30). Notez également que la Vsync est générée en même temps que le border, donc la Vsync est comprise dans les 8*8 lignes de border suivante, Tant que j'y suis sur les lignes, je vous fait remarquer qu'en tout, et en standard le CRTC affiche 312 lignes. En effet, il affiche 39 lignes physique (on peut les appeler comme ça (reg 4=38, et on démarre à 0)) de 8 lignes de haut (reg 9+1), soit 312 lignes. Sachant qu'une ligne fait 64 NOPs, alors un écran est fait en 19968 NOPs. Un NOP=1 microseconde, donc un écran est balayé en 0.019968 seconde. Combien d'écran balayé en 1 seconde ?
 
 règle de 3 : 1/0.019968-50,0801
 
@@ -176,7 +175,7 @@ La valeur 1 permet de décaler l'écran d’une demie ligne à chaque balayage,
 Il est toujours possible d'essayer de “bidouiller” quelque chose avec ce registre 8, ca n'a pas encore été fait dans une démo par exemple, alors, pourquoi pas ??? A vous de voir !
 Bon, après avoir vu le fonctionnement du CRTC en horizontal, on peut tirer quelques règles de calcul et de fonctionnement à respecter pour que le CRTC travail correctement. Les voici :
 
-nb lignes = sum(val reg 4 + 1) * sum(val reg 9 + 1) + sum(val reg 5)
+	nb lignes = Σ(val reg 4 + 1) * Σ(val reg 9 + 1) + Σ(val reg 5)
 
 Le nombre de ligne doit toujours faire (approximativement) 312 lignes pour avoir un écran stable. (en fait, il faut que le nombre de linge soit identique d'une synchro à une autre pour avoir un écran stable). I est bon de respecter cette règle de calcul le plus souvent possible. Pourquoi avoir mis E des valeur ?? Car c’est la somme des différentes valeur des registres pendant 1 écran, mais nous en reparlerons plus tard.
 
@@ -217,7 +216,7 @@ En ce qui concerne le registre 3, celui ci donne simplement la largeur en NOP (m
 
 De ces informations, on peut extraire quelques règles de fonctionnement :
 
-	5: sum(val reg 0 + 1) = 64
+	5: Σ(val reg 0 + 1) = 64
 
 Chaque ligne doit faire 64 colonnes, sinon, le canon à électron ne peut pas se synchroniser correctement.
 
@@ -260,16 +259,16 @@ Quelques explications sur les valeurs choisies :
 
 - registre 6 = 36 : permet d’avoir toute la hauteur du moniteur.
 
-- registre 7= 34 : positionne l'écran en haut du moniteur.
+- registre 7 = 34 : positionne l'écran en haut du moniteur.
 
-- registres 12-13 =#2C10 : tout d’abord, la bank de départ est la bank n°2 (#8000-#BFFF), avec les bits 5-4 à 10. Ensuite, la taille de la page est de 32ko (bits 3-2 à 11), et enfin, l'offset de la page commence à #0010, soit l'adresse mémoire #8020. Cette valeur permet d’avoir un transition sans problème entre les 2 banks de 16ko (#8000-#BFFF puis #C000-#FFFF). En effet, dans 16ko, on peut avoir au maximum 21 lignes complètes de caractères de 96 octets de large, soit en taille mémoire 96*21*8 = 16128 octets, il reste donc 16384-16128 = 256 octets soit 1 ligne caractère de 32 (= #20) octets de large. Il est donc judicieux d'enlever ces 20 octets de l'écran overscan, et donc d'avoir exactement 21 lignes de 96 octets de large, ainsi, la transition entre les 2 banks mémoire se fera d’une ligne caractère à une autre (et pas en plein milieu de la dernière ligne de la première bank...).
+- registres 12-13 = #2C10 : tout d’abord, la bank de départ est la bank n°2 (#8000-#BFFF), avec les bits 5-4 à 10. Ensuite, la taille de la page est de 32ko (bits 3-2 à 11), et enfin, l'offset de la page commence à #0010, soit l'adresse mémoire #8020. Cette valeur permet d’avoir un transition sans problème entre les 2 banks de 16ko (#8000-#BFFF puis #C000-#FFFF). En effet, dans 16ko, on peut avoir au maximum 21 lignes complètes de caractères de 96 octets de large, soit en taille mémoire 96*21*8 = 16128 octets, il reste donc 16384-16128 = 256 octets soit 1 ligne caractère de 32 (= #20) octets de large. Il est donc judicieux d'enlever ces 20 octets de l'écran overscan, et donc d'avoir exactement 21 lignes de 96 octets de large, ainsi, la transition entre les 2 banks mémoire se fera d’une ligne caractère à une autre (et pas en plein milieu de la dernière ligne de la première bank...).
 
 Voilà, j'en ai fini avec l’'overscan, bien sur, cet exemple n’est qu’un exemple d’overscan possible, il y a bien d'autres redimensionnement d’écran qui peuvent être fait. Par exemple, essayez de voir comment on peut simplifier grandement le BC26 avec un écran de 64 octets de large !
 
 ### 2) Le split-CRTC
 
 Beaucoup me demanderons ce qu'est le “split-CRTC”.. Avez-vous déjà vue un scroll en split raster ? N'avez-vous jamais vu ce genre de scroll au dessus d’un dessin en 4 ou 16 couleurs, comme dans la Vectrix part d’Elmsoft, ou encore dans Prehistorik 2 du même (génialissime) auteur ? La question que je me suis longtemps posée était comment ce bougre a-ti fait pour changer 4 encres en seulement 4 cycles. Et bien il ne l’a pas fait ! En fait, et c'est le principe du split-CRTC, ce que l’on voit n'est pas de l’écran mais du border, ce qui permet de faire défiler un texte sur un graphe sans problème.
-On peut done, grâce au CRTC faire afficher, un coup de l'écran, un coup du border... Bien sûr, cet effet doit être codé dans une synchro, c’est à dire synchronisé sur la Vbl du CRTC, récupéré grâce au PPI, mais je n’expliquerais pas ceci dans ce cours, en supposant que Vous avez déjà codé un simple raster ou mieux un split raster dans le cas présent.
+On peut done, grâce au CRTC faire afficher, un coup de l'écran, un coup du border... Bien sûr, cet effet doit être codé dans une synchro, c’est à dire synchronisé sur la VBL du CRTC, récupéré grâce au PPI, mais je n’expliquerais pas ceci dans ce cours, en supposant que Vous avez déjà codé un simple raster ou mieux un split raster dans le cas présent.
 Le principe du split-CRTC est donc de faire alterner écran et border sur une ligne, et ceci ce fait grâce aux registre 6 sur les CRTC 1 et 4, et au registre 8 (buggé !) sur les CRTC 0 et 3.
 
 Pour ce qui est du CRTC 1 et 4, on modifie le registre 6 (qui correspond à la hauteur de
@@ -280,13 +279,13 @@ Voilà pour cette petite ‘bidouille’ du CRTC qui peut-être utile de temps e
 ### 3) La rupture horizontale
 
 Là démarre vraiment l’une des techniques intéressantes permettant d'exploiter au mieux le CRTC. Tout d’abord, la rupture horizontale, inventée par Longshot, avait pour but de “découper” l'écran en hauteur, permettant ainsi d’avoir des offsets différents pour chaque zones écrans’. Pourquoi vouloir découper l’écran en hauteur et changer les offsets plusieurs fois pendant une synchro ???
-Tout d‘abord, au niveau de la mémoire, cela permet d’avoir une zone écran entre #4000 et #7FFF, et une autre entre #C000 et #FFFF par exemple. On peut donc arriver à avoir un écran pseudo-overscan sans utiliser une zone mémoire de 32K0, mais 2 zones de 16Ko, ce qui permet dans ce cas d'éviter de sauvegarder le système d'exploitation comme expliqué dans le chapitre 1 sur l’overscan.
+Tout d‘abord, au niveau de la mémoire, cela permet d’avoir une zone écran entre #4000 et #7FFF, et une autre entre #C000 et #FFFF par exemple. On peut donc arriver à avoir un écran pseudo-overscan sans utiliser une zone mémoire de 32Ko, mais 2 zones de 16Ko, ce qui permet dans ce cas d'éviter de sauvegarder le système d'exploitation comme expliqué dans le chapitre 1 sur l’overscan.
 Ensuite, pouvoir changer les offsets des zones écrans indépendamment les uns des autres pendant une synchro permet par exemple de faire défiler une zone écran (grâce à l’offset) en ayant une autre zone écran fixe. Vous avez sûrement déjà vu des scrolls-text relativement rapide, réalisé grâce à une rupture horizontale, cela permet de faire défiler une zone mémoire importante en seulement 2 adressages de CRTC (reg 12 et 13)! Essayez de faire un scroll-text de 32 lignes de haut par 96 octets de large en 14 lignes de temps machine sans utiliser le “hard” du CRTC ! Mais ceci n’est qu'un exemple d’utilisation de rupture horizontale, il y a beaucoup d'avantage à utiliser cette technique, en général, on y gagne en fluidité par rapport au même effet qui serait réalisé en soft.
 
-La technique de la rupture horizontale consiste à changer plusieurs fois, si nécessaire, la hauteur physique (reg 4) de l'écran pour qu’un nouvel offset soit pris en compte pour chaque zone écran. En effet, l'offset est rechargé à chaque fois que le compteur de ligne caractère interne) repasse à 0, donc quand la valeur du registre 4 est atteinte par ce compteur. Si on respectait à la lettre la règle 1 (val reg 7 <= val reg 4), alors le CRTC générerait à chaque zone écran une Vbl, ce qui n'est pas propre. Pour éviter de générer une VBL à chaque zone écran, il faut mettre le registre 7 à l’overflow en début de synchro, ensuite le CRTC va générer les différentes zone écran, et a la fin de synchro, il faut indiquer au CRTC qu'il doit générer une VBL (et une seule par écran complet !) pour que le moniteur puisse se synchroniser correctement.
+La technique de la rupture horizontale consiste à changer plusieurs fois, si nécessaire, la hauteur physique (reg 4) de l'écran pour qu’un nouvel offset soit pris en compte pour chaque zone écran. En effet, l'offset est rechargé à chaque fois que le compteur de ligne caractère interne) repasse à 0, donc quand la valeur du registre 4 est atteinte par ce compteur. Si on respectait à la lettre la règle 1 (val reg 7 <= val reg 4), alors le CRTC générerait à chaque zone écran une VBL, ce qui n'est pas propre. Pour éviter de générer une VBL à chaque zone écran, il faut mettre le registre 7 à l’overflow en début de synchro, ensuite le CRTC va générer les différentes zone écran, et a la fin de synchro, il faut indiquer au CRTC qu'il doit générer une VBL (et une seule par écran complet !) pour que le moniteur puisse se synchroniser correctement.
 De plus, pour que l'écran complet soit stable, il faut que le total des lignes affichées par le CRTC soit toujours égal à 312, donc que la somme des hauteurs des zones écran soit égal à 38. Je vous rappel que les valeurs envoyés au registre 4 sont égale à la hauteur de la zone écran moins un, car le compteur de ligne caractère démarre à 0.
 
-nb lignes = sum(val reg 4 + 1) * sum(val reg 9 + 1) + sum(val reg 5) = 312
+	nb lignes = Σ(val reg 4 + 1) * Σ(val reg 9 + 1) + Σ(val reg 5) = 312
 
 Un petit schéma expliquant comment réaliser ce genre d'effet :