Vomitiks #03 : « Sur CRTC 1, tout est bien plus simple ! »

Dans 64NOP numéro 2, pages 36 à 38, on peut lire un article intitulé « VIVE LE CRTC 1 ONLY ». Hicks y évoque son droit à exploiter le plein potentiel du CRTC 1.

Il réfute que « les démos soient plus simples sur CRTC 1 » et se livre à un savant numéro d’équilibriste pour essayer de le justifier.

En préambule, il est utile de préciser que lorsqu’il est question de modifier le pointeur vidéo, le CRTC 1 est sans conteste beaucoup plus simple à programmer que les autres CRTCs.

Cette technique, au sens général, est appelée « RUPTURE ». Dans le monde de la démo CPC, la rupture est la technique la plus utilisée et la plus répandue.

L'auteur évoque deux parties de sa démo "FROM SCRATCH" pour faire sa démonstration. Il va comparer la difficulté de réalisation entre le CRTC 1 et le CRTC 0 alors même que cette démo n'a pas été adaptée sur le CRTC 0 :

Sur la première partie (WOBBLER), il ecrit que la difficulté serait similaire sur CRTC 0 et 1 concernant la technique de RUPTURE employée.

Sur la seconde partie (SCROLL), il tente de justifier que la difficulté est plus grande sur CRTC 1 que sur le CRTC 0 pour pouvoir utiliser une technique dite de SPLITBORDER.

WOBBLER facile !

L'auteur tente de faire croire que la technique dite de RVI (un type de rupture particulier élaboré par Overflow en 1991) sur sa partie « WOBBLER » présente les mêmes difficultés sur CRTC 1 que sur CRTC 0.

Toute chose étant relative quand on parle de difficulté, c’est absolument faux.

Il évoque d'ailleurs la facilité de réaliser une « petite RVI » sur le CRTC 2, mais il s’est bien gardé de la réaliser pour sa partie « WOBBLER », et parle donc d'une chose qu'il ne connait pas du tout.

SCROLLS MULTIPLES SOUS PERFUSION

Il est nécessaire de préciser que la technique de SPLITBORDER est utilisée de manière anecdotique dans le monde de la démo, et ne peut donc pas servir de base pour faire des généralités sur la difficulté d'usage du circuit dans les démos.

Après avoir minimisé la difficulté sur CRTC 0, l'auteur indique que sa partie "SCROLLS MULTIPLES" serait plus compliquée à faire sur CRTC 1 que sur CRTC 0.

C'est sans aucun doute car il ne savait pas exploiter toutes les facilités du CRTC 1 ou plus simplement qu'il s'est pris les pieds dans le tapis, même avec les solutions techniques disponibles "à l'époque".

Bref, Hicks a réalisé sa partie comme il le pouvait, et a trouvé ça difficile. Personne ne va en douter ou lui jeter la pierre, mais il y a ici clairement un amalgame entre la difficulté qu'il a rencontré par ignorance et la réalité factuelle du circuit. Et si réaliser cette partie lui parait plus simple sur un CRTC 0, c'est bien dommage qu'il ne l'ait pas adaptée, plutôt que de juste en parler.

Ce n'est d'ailleurs pas la seule fois ou l'auteur se complique inutilement la vie car il ne connait pas assez bien la machine (*).

Hicks admet ici que le CRTC 1 a toujours été bien plus simple que tous les autres CRTCs. On se demande d'ailleurs ou il y a une quelconque évidence "15 ans plus tard", puisqu'il raconte une nouvelle ânerie technique en évoquant la technique RFD sans la nommer explicitement. Le « Sick mode » du CRTC 1 n’était-il pas en état végétatif dans les  commentaires du source d’un émulateur depuis 30 ans ?

Il est inexact de raconter que "cela égaliserait le difficulté globale entre CRTC 0 et 1", puisque des ruptures sur d'autres CRTCs que le 1 nécessitent de construire un frame à 50Hz et savoir le synchroniser, ce dont on peut totalement se passer sur CRTC 1 en RFD (La "Rupture for Dummies" porte bien son nom!).

Pour finir sur cette "partie", et même si des dizaines de scrollings n'ont pas plus d'intérêt que ceux, novateurs, réalisés dans la première partie de Amazing Demo 25 ans auparavant, je vais ajouter qu'elle pourrait sans doute être adaptée sur tous les CRTCs si certains en doutaient. Cela ferait sens pour ceux qui évoquent à tout bout de champ le "demospirit" ou les "world record" dans le mauvais sens.

Je vais conclure ce billet en rappelant qu’une des bases du "demospirit" repose sur un travail de recherche qui semble s’être arrêté dans les années 90 sur CPC, à quelques exceptions près. Dans ces exceptions, on trouve notamment les judicieuses expérimentations de Rhino avec le registre 2 pour atteindre des 1/2 pixels ou quelques études sommaires délivrées par Madram dans le fanzine Amslive...

Et qui sait si le CRTC 2 (ce composant qualifié péjorativement par l'auteur de "bas de gamme") ne contient pas des bugs intéressants ?

Peut-être cachés derrière des commentaires oubliés dans un émulateur...

Longshot / Logon System

(*) Lorsqu'un programme informatique est réalisé avec de mauvaises bases, on peut en général s'attendre à des difficultés pour la suite. C'est un peu comme les fondations d'une maison qui seraient réalisés en carton, alors qu'on veut y poser des briques en ciment. On comprend rapidement que construire la maison va être difficile.

Pour revenir au sujet, et en dehors du cas de la partie évoquée en référence, ce fut par exemple également le cas dans l'introduction de la démo "DenScreen", sortie en 2018, qui présente un écran dont la partie gauche est en mode graphique 1, et la partie droite en mode graphique 0 :

Sur un CPC, cette technique de changement de mode en cours de ligne présente peu de difficultés puisqu'elle est connue depuis 1989, et a été utilisée dans plusieurs démos créées durant les années 90. Ci-dessous une démo (non publique) réalisée par Duncan où on peut voir les zones noires HSYNC encadrant le logo "Logon" en mode 0 sur un scrolling en mode 1.

Cette technique a été décrite dans des forums et documentée sur internet, notamment sur le portail de MrEarwig (je n'en ai cependant trouvé aucune trace dans Paris match) :

D'un point de vue technique donc, il faut que le CRTC "présente" une HSYNC d'une longueur de 2 µsec minimum au GATE ARRAY pour que ce dernier "accepte" de changer le mode graphique. C'est assez simple à vérifier, surtout lorsqu'on réalise une démo compatible sur 2 CRTCs sur 5, au lieu de prendre à la lettre les informations erronées publiées 22 ans auparavant dans le fanzine Quasar numéro 11 (octobre 1996).

Deux micro-secondes : Ni plus ni moins, même si le Compendium (chapitres 9.3.1 et 9.3.4) explique comment réduire visuellement cette zone de 0.25 µsec. Cela a notamment permis de récupérer quelques pixels pour l'affichage des ":" avant le nom des auteurs dans la démo DSC#4. Cela ne semble néanmoins pas encore traité par de nombreux émulateurs.

Tant que le signal HSYNC dure moins de 2 µsec, l'effet sur le moniteur est pratiquement nul. Il se traduit par l'affichage de la couleur noire par le GATE ARRAY.

Comme on le voit avec les explications techniques ci-dessus, au lieu d'utiliser les connaissances techniques actualisées déjà à sa disposition "à l'époque", ou d'avoir fait une simple petite recherche technique (10 minutes chrono), l'auteur de la démo a provoqué un problème "analogique" du moniteur qu'il a ensuite tenté de compenser. Il a donc inutilement complexifié son code pour atteindre son objectif, tout en affectant potentiellement la compatibilité de sa démo avec certains écrans.

Rien de bien grave si on aime les choses compliquées, mais ça ne peut en aucun cas servir de démonstration pour décréter que, de manière générale, le GATE ARRAY est plus difficile à programmer lorsqu'on veut changer de mode graphique en cours de ligne, et notamment si on compare ça avec un code ayant fait la même chose de manière plus simple.