Vomitiks #05 : Sink Mode !

L'article présent dans 64NOP numéro 2, pages 36 à 38, est classé dans une catégorie "polémique". On se demanderait presque pourquoi....

🙄

Bullshit : L'auteur participe à une forme de révisionnisme technique en ne citant pas la RFD comme étant la technique réellement utilisée par la démo DSC #4 et laisse croire qu'il s'agit de l'application d'une règle issue d'une verrue réalisée dans l'émulateur ACE.

💬

« L’offset est pris en compte quand C4=0 (....) ou quand C0=0 si R1>R0 » Hicks, 64Nops 2, page 37

💬

« Evidemment, 15 ans plus tard, cette dernière partie pourrait être simplifiée en fixant R1>R0, afin d’éviter d’avoir à mettre R4=0 » Hicks, 64 Nops 2, page 38

L'auteur essaie de justifier pourquoi son code lui a paru plus difficile à faire sur CRTC 1 que sur CRTC 0 dans sa démo "From Scratch" : j'ai déjà abordé ce sujet ici

Bien qu'elle ne soit pas citée explicitement dans son article, c'est la technique sur CRTC 1 nommée RFD (Rupture For Dummies) qui est évoquée ici. Cette technique, présentée dans le Compendium depuis 2 ans, est utilisée pour la première fois dans la démo DSC#4.

Elle porte ce nom car, contrairement aux autres techniques de rupture, elle ne nécessite pas la mise à jour dynamique des registres permettant de synchroniser l’image sur le moniteur ni de créer plusieurs "frame" en 1/50^ème de seconde (un cauchemar pour les personnes qui débutent en "rupture" sans guide).

Autrement dit, cette technique simplifie très grandement les choses et rend le CRTC 1 encore bien plus simple à utiliser pour les ruptures qu’il ne l’était déjà auparavant.

Un peu d’histoire, afin de prévenir toute forme de révisionnisme technique...

💡

A l’origine, la technique RFD découle du constat d’un bug visuel sur la mise à jour du registre R5 avec une valeur non nulle sur une position précise (lorsque C0=R0). Cet artefact visuel pouvait être péniblement mis en évidence via un test réalisé par Arnoldemu (Kevin Thacker) (en appuyant des milliers de fois sur une touche) et avait également été commenté sur CpcWiki. Ce bug est resté un phénomène instable et incompris, vite oublié (ou commenté) par certains. Ce bug a été étudié dans le Compendium, qui a mis en évidence sa relation avec différents états internes du CRTC, dont celui de la mise à jour du pointeur VMA, mais aussi ceux du mode interlace IVM et de sa parité concernant le comparateur C9/R9. A l’issue de ces études, la technique de RFD a été présentée dans le Compendium avec son mode d’emploi simplifié. Cette étude a également permis d’identifier 2 variantes du CRTC 1 (#1A et #1B).

DSC#4 est une petite démo qui met en évidence la technique RFD lorsqu’elle est lancée sur le CRTC 1. Lors de sa sortie, l'auteur de l’émulateur ACE a commenté la démo sur le portail « Pouet » en affirmant que « c’est intéressant, même si il s’agit d’une fonctionnalité connue du CRTC 1 » (traduit de l'anglais).

Il va également indiquer dans l’historique de la version 1.26 de son émulateur que ce « mode spécial avait été désactivé il y a assez longtemps car il n’était pas encore bien compris et peu fiable » en le qualifiant de "mode malade" ("sick mode" en anglais).

Le technique RFD n'est, ici non plus, jamais mentionnée. En référence à DSC #4, cette technique se trouve ainsi réduite a un bug connu de tous depuis longtemps, réactivé par la suppression d’un commentaire oublié dans l'émulateur ACE et rapidement corrigé. Et hop !

Sur plusieurs médias ou réseaux sociaux dédiés au CPC, on va ainsi pouvoir lire ce genre de choses, propagé par un petit groupe de personnes :

💬

"Concernant cette dernière intro [DSC 4], c'est quelque chose qui a été découvert par Arnoldemu en 2014, mais son utilisation est effectivement inédite" (Tot0, Gamopat forum, 6 nov 2023)

Pourtant, face à cette manière assez singulière de présenter les choses, j'ai fait une mise au point en novembre 2023 sur le portail CpcWiki en rappelant que la RFD n'est pas un "Sick Mode", en réponse à l'auteur de l'émulateur Mist qui venait de constater l'inefficacité de la règle de gestion du "bug" énoncée par l'auteur de l'émulateur ACE :

💬

"I think that the "sick mode" that you apply is nonsense.
This explains the regressions you encounter on Mist with other demos.
"Sick mode" is the simple observation of a phenomenon that remained unexplained until the Compendium.
In effect, an unexplained phenomenon had been detected when setting R5>0 on C0=R0.

The Compendium explains and documents all of the CRTC logic behind this bug since version 1.2.
This has given rise to a new technique called RFD that allows you to modify the offset on each line on the CRTC 1.
The answer to your question is found in the sentence following the one you quoted.
You just need to read the chapter completely to understand how it works.
This is how DManu78 implemented it correctly in Amspirit.

Version 1.7 of the document is available at https://shaker.logonsystem.eu"(Longshot, Cpc Wiki, 6 nov 2023)

Un commentaire sur le "bug R5" existait sans nul doute dans ACE, même si ce n'était connu de pratiquement personne et semble-t-il oublié de tous. On ne sait d'ailleurs pas ce qu'il y avait exactement "derrière" ces lignes commentées : Un "bug buggé" ?

Pour exploiter une technique de RFD (ou l'émuler), il faut avoir décortiqué et compris le rôle de ce bug R5 et bien d'autres fonctions et états internes du CRTC. Et pas des moindres, puisque ça implique le mode "interlace" !

Or ce n'est pas ce qui a été émulé et cela laisse croire (à tort) que la chose se règle facilement avec une règle en bois. La RFD n'est toujours pas émulée ou comprise correctement à l’heure ou j’écris cet article (février 2024). Pour ceux qui en douteraient, la version révisée de DSC #4 qui est sortie le 28 octobre 2023 ne fonctionne pas sur les émulateurs:

DSC #4 sur ACE-DL en Crtc 1 (et qui ne fonctionne pas non plus sur les autres CRTCs)

A ma connaissance, seul l'émulateur Amspirit est capable d’émuler cette version sur le CRTC 1, car l'auteur a appliqué les règles décrites dans le Compendium.

Il est particulièrement étonnant qu’au lieu de chercher à comprendre le fonctionnement de la RFD en lisant le Compendium pour implémenter correctement les traitements et bugs CRTC associés, l’adaptation de DSC #4 sur ACE soit passée par une nouvelle verrue. Cette verrue découle d’une simple supposition pifométrique à partir de la valeur des registres "constatés" lors d’un arrêt de la démo via un debugger. Les verrues sont contagieuses puisque d'autres émulateurs ont également utilisé ces déductions fantaisistes. Pourtant, le Compendium est aussi destiné aux auteurs d'émulateurs pour éviter ce genre d'approximation. Le portail Shakerland a été spécifiquement créé pour les aider à progresser sur ce sujet et des modules de tests permettent de valider les développements en comparant le résultat des tests avec le hardware réel:

Portail Shakerland / RFD CRTC 1, Hardware et ACE

Aucune chance donc que le CRTC 1 soit émulé correctement !

Il est encore plus étonnant que l'auteur de l'article et quelques personnes dans son entourage se contentent de propager ce type d’information erroné sans même l’ombre d’une vérification technique (pourtant très simple à faire pour ces experts techniques de la machine, mais c'est très certainement involontaire de leur part 😂 ). A défaut, prendre 5 minutes pour constater dans le Compendium que les choses ne sont pas aussi simples qu’un bug « sick mode » connu depuis 30 ans (en référence aux propos d'un âgiste râgeux, grossier, menteur et toxique dont on ne prononcera pas le nom ici). L'auteur de l'article raconte à qui veut l'entendre que le Compendium ne serait pas assez clair (pour rester poli). Il est facile de juger le contraire sur l'extrait ci-dessous, qui vulgarise la technique RFD pour ceux qui n'ont pas envie de comprendre la logique interne du circuit :

Méthode pratique pour gérer une RFD pour s'affranchir d'en comprendre la logique

Aucune chance donc que le CRTC 1 soit correctement compris et donc bien exploité !

Dans ce contexte, ne jamais citer la RFD en tant que nouvelle technique pour pouvoir la réduire à un bug rapidement corrigé me semble être une stratégie malhonnête.

Tout comme il est malhonnête de s'approprier le travail d'autrui sans citer ses sources.

Je terminerais par « R1>R0 ».

Chauffe, Marcel !

Longshot / Logon System