Archive: Rupture Verticale (31 Août 1992)
Pour inaugurer la section ‘archives’, voici un courrier daté du 31 Août 1992, que j’ai reçu de la part de Longshot. Il y décrit l’état déjà bien avancé de la compréhension de la rupture verticale, technique révélée pas la célèbre S&KOH , sortie en Novemlre. J’ai retranscrit ici le texte intégral de l’explication (avec une correction apportée par son auteur), car le texte est plutôt clair étant donné la complexité du sujet. J’ai refait les schémas pour une meilleure visibilité. Pour accéder au scan des courriers originaux, ainsi qu’à un espace de discussion, ca se passe sur le forum.
Je vois que tu as bien pigé la rupture ligne à ligne, et que tu ne fais pas comme beaucoup de monde qui veulent savoir ce qui est la RVI (l’adressage de plusieurs blocs) avant de maîtriser totalement la Rupture Horizontale (RH), qui est la rupture que tu as utilisé jusqu’alors.
Tu me demandes comment avoir plus de blocs (puisque tu t’es malheureusement aperçu que l’offset démarre toujours et seulement sur le premier bloc de 2048 octets soit 2048*4 pages : 8192 octets en ligne a ligne, ceci en supposant qu’on ne peut plus servir du reste, même en modifiant R9, puisque les premiers blocs servent à autre chose…)
Bref, la solution fût trouvée par Overflow à l’aide de techniques que je n’avais pas exploitées complètement: la Rupture Verticale. La Rupture Verticale avait pour but, à l’origine de couper l’écran en 2 (ou plus), pour changer de mode graphique (uniquement possible durant 1 HBL de au moins 2μs ) ou d’offset..
Ainsi, tout comme en RH, le R0 contient le nombre de μs sur une ligne, soit 63 (+1) = 64μs (sur tous les ordinateurs, puisque cette valeur dépend de la fréquence de balayage du moniteur.. 0.000064sec*312.5 = 0.02sec, soit 1/50ème, .. 50Hz!) . Si R0=31, alors le CRTC générera un split au milieu des 64μs de 2×32μs. La largeur de la bande HBL (qui ne compte pas dans les 64 μs mais est juste une zone noire en surimpression visuelle) est déterminée par R3. Cette zone noire correspond à peu près à R7 car elle a un rapport avec la synchro de l’image (synchro horizontale) et sa position est déterminée par R2..
Bref, il est nécessaire que la zone sync du moniteur (qui dure quelques μs) soit en parallèle avec celle du CRT pour que l’image soit stable horizontalement. (R3 dois être au moins à 7 dans le bord (a vérifier) et bien sûr au minimum au centre (au moins à 1 (2μs )) pour un changement de mode). Il va sans dire qu’il faut déjà être en ligne-à-ligne pour faire tout ca (bonjour la brochette de registres).
D’ailleurs un détail facilitant la vie… OUTI marche partout mais il PRE-décrémente B. Donc pour le Gate Array., B doit être égal à #80 pour le CRTC (#BE00 -> donnée, #BD00 -> select)
Venons en maintenant à l’adressage des blocs (ce que j’ai expliqué plus haut étant mes expériences d’il y a 2 ans..) Voila le principe (c’est un exemple!)
Hum… j’espère que le schéma t’aide un peu à piger. Bref R0 est à 49 (50μs) durant le main screen (pendant ce temps, et avec une bonne dose d’optimisation R12,R13 et R9 peuvent être changés!)
Puis (c’est une exemple puisqu’il y a d’autre méthodes, notamment la SPLIT 1-8 et la méthode DUNCAN) R0 passe à 1, et le CRTC génère dans la HBL des écrans de 2μs ! (plus petit, ça commence à déconner (c.a.d R0=0 ! … encore que … 1μs …)
Bref, selon le numéro du bloc courant et la valeur de R9 (qui en fait, compte les ruptures) on a :
Dans cet exemple, R9 durant A est mis à 4, ce qui provoque un bloc 3 en B … pas évident, n’est-ce pas?
Il y a cependant des problèmes de CRTC. Sur type 0 il est très dur d’obtenir 7 ruptures en HBL sans anomalie (dans le compteur). Pas mal de contraintes aussi puisque R9 ne doit JAMAIS passer à une valeur inférieure au bloc courant. En fait pour tout dire, le record de blocs indépendants (RVI, Rupture Verticale Indépendante) est de 5, tous CRTCs confondus, et a été trouvé par DUNCAN.Le CRTC type 1 est le mieux armé pour la RV car il ne génère aucun temps entre 2 ruptures verticales (au contraire du CRTC 0, ce qui fait ses problèmes) . Bref si R3 est à 0 sur type 1* et que R0=7 ( 8μs ), on génère un split de 8×8 μs (SPLIT 1-8), ce qui donne:
et permet dont d’avoir tous les blocs sur une ligne, donc d’avoir plus de Ram Vidéo … bien sur … c’est plus chiant à gérer… et ca ne marche pas du tout sur type 0 car même avec R3 à 0, le CRTC génère une zone « visuelle » de 1 octet environ…
(*) Note de Longshot:
Avec le recul, et concernant le SPLIT 1-8 Il est inexact, dans cette situation, d’écrire que R3=0 lorsqu’on splitte en cours d’affichage, car ça suppose que la HBL a lieu. C’était une mauvaise interprétation de ma part : ça marchait car R2 était juste supérieur à 7 dans l’exemple, et il était positionné 1 fois entre 0 et 7 dans une des périodes de 8 µsec pour que l’écran se synchronise. La valeur de R3 n’a aucune importance. Elle doit juste être assez grande pour permettre une bonne synchronisation horizontale du moniteur sur le signal HBL du CRTC.
Je pense que j’ai fait cette confusion car la première fois que j’ai touché à R0 en cours de ligne début 1990, c’était pour changer de mode graphique, et non changer l’adresse. J’étais fasciné par un soft graphique sur Atari ST qui y était arrivé dont je ne me souviens plus du nom. Et lorsqu’on veut changer de mode, une HBL courte au milieu d’une ligne s’impose. Mais pour changer d’adresse, aucune HBL ne s’impose et c’est même à éviter, d’autant que placer R3 à 0 correspond à une longueur de 16 µsec sur certains CRTCs. C’est pourtant ainsi que Overflow a fait sa première rupture en cours de balayage dans l’intro de la S&KOH
