Dans l'article précédent, je parlais de la philosophie générale d'AMSpiriT Lite, et notamment de cette API web qui le distingue de la plupart des émulateurs CPC : une interface REST toute bête, qu'on peut interroger avec curl depuis un terminal, mais qui ouvre en réalité la porte à des usages qu'on n'imaginerait pas avec un émulateur « fermé ».

Cette série a pour but de revenir en détail sur les principaux endpoints et les fonctionnalités phares de l'émulateur. Mais plutôt que d'aligner une liste d'endpoints, ce qui serait vite rébarbatif, on va procéder à partir de cas d'usage concrets. Dans ce billet, on commence par l'un des endpoints les plus utilisés, /api/ram, en l'illustrant avec un petit outil : le Curve Injector.

Cet outil, disponible sur le dépôt GitHub amspirit-releases, est un générateur de courbes qui tourne dans un navigateur (c'est une simple page web), et qui permet d'écrire les données générées directement dans la RAM de l'émulateur. Rien de plus, rien de moins – mais ce « rien de plus » ouvre pas mal de portes. Et comme on aime expérimenter, on va piloter le tout avec un périphérique MIDI. Voici une vidéo pour illustrer comment ça se passe :

L'outil est né d'une situation classique en cours de développement : on veut régler une table de valeurs pour caler une animation. Quand on fait cela, on tâtonne : on essaye une formule, on réassemble, on transfère, on teste, et on recommence. On passe son temps à remplacer la table sans toucher au reste du code. Comment simplifier ces allers-retours ?

Comme l'écriture en RAM peut être pilotée par une API HTTP accessible depuis n'importe quel programme, la réponse la plus rapide n'était pas « je recompile et je recharge », mais « j'écris une page web qui génère la table et la pousse en RAM en direct ». Et ça marche même sans le code source : il suffit qu'un programme tourne dans l'émulateur, et qu'on sache à quelle adresse injecter les données.

Repris et retravaillé, l'outil propose aujourd'hui :

• un générateur paramétrique (sinus, triangle, dents de scie, carré, impulsion, bruit), dont on règle le centre, l'amplitude, la période, la phase et le rapport cyclique,
• un mode équation (une expression JavaScript, pour les cas que le mode paramétrique ne couvre pas),
• un mode dessin libre à la souris,
• un panneau Output Encoding pour filtrer la sortie : bornes et masques numériques en mode Data, ou conversion directe en couleurs via le mode Gate Array,
• et un contrôle MIDI optionnel sur chaque paramètre.

Le tout tient dans un unique fichier HTML autonome – pas de serveur, pas de build : on double-clique dessus et ça marche. Piloter un CPC émulé depuis un clavier MIDI n'est probablement qu'un exemple parmi d'autres de ce que cette API ouverte rend possible. Voyons tout cela de plus près !

Allô, AMSpiriT ?

Le point de départ de tout ça, c'est qu'AMSpiriT expose une petite API REST sur http://127.0.0.1:6128, que l'on active à la demande. La plupart des exemples de l'article précédent reposaient sur deux endpoints : /api/ram, pour lire et écrire la mémoire, et /api/screenshot, pour récupérer une image de l'écran. On commence ici par le premier des deux, puisque c'est lui qui fait tout le travail dans le Curve Injector. Mais avant toute chose, il faut s'assurer que l'on arrive bien à dialoguer avec AMSpiriT.

/api/ping : un premier coup de sonde

Avant de se lancer dans quoi que ce soit, il faut vérifier que tout ce petit monde est bien réveillé. C'est le rôle de /api/ping, qui renvoie l'état global de l'émulateur. C'est d'ailleurs le premier endpoint qu'appelle le Curve Injector au chargement de la page.

Avec AMSpiriT lancé sur la machine, il suffit d'ouvrir l'URL http://127.0.0.1:6128/api/ping dans un navigateur :

On obtient le même résultat avec la commande curl dans un terminal :

$ curl -s http://127.0.0.1:6128/api/ping

{"ok":true,"emu":{"fps":50.1,"frame_ms":11.8,"frames":32395,"paused":false,
"cpc_model":"6128","crtc_type":0,"autotyping":false,"autotype_remaining":0,
"tl_active":false,"tl_steps_back":0,"tl_steps_fwd":0,"tl_step_kind":"frame",
"ram_apply_seq":0},"frontend":"lite","version":"1.15.4","core":2491682}

Voici le détail des champs :

• frontend, version et core permettent d'identifier la version exacte d'AMSpiriT : ici la version Lite 1.15.4, avec l'identifiant du core d'émulation.
• emu renseigne sur la machine émulée et son état global. En particulier :
  • cpc_model et crtc_type identifient le type de machine émulée.
  • frames donne le nombre de frames émulées depuis le démarrage, et sert d'horloge de référence. Tant qu'il reste à 0, le Z80 n'a pas encore exécuté une seule instruction, même si le serveur HTTP, lui, répond déjà.
  • autotyping et autotype_remaining renseignent sur la saisie automatique de texte en cours. C'est utile pour attendre la fin d'un envoi de texte avant d'enchaîner sur autre chose, mais ça ne nous concerne pas ici.
  • tl_active, tl_steps_back, tl_steps_fwd et tl_step_kind décrivent l'état du timelapse (le retour en arrière/avant dans l'exécution). C'est là aussi hors sujet pour le Curve Injector.
  • ram_apply_seq est un compteur d'écritures en RAM effectivement appliquées. Celui-ci va nous intéresser : on en parle juste en dessous.

Jeter l'encre

Le Curve Injector, comme son nom l'indique, écrit des données en RAM. Pour ce faire, il suffit d'envoyer une requête POST avec un corps JSON :

curl -s -X POST http://127.0.0.1:6128/api/ram \
    -H "Content-Type: application/json" \
    -d '{"addr": 49152, "bank":0,
         "data" : "ed5fe61ff64001107fed49ed7918f1",
         "exec":true, "entry": 49152 }'

{"ok":true,"seq":1}

Ici, on écrit une séquence d'octets, passée sous forme de chaîne hexadécimale (data), à l'adresse 49152 : c'est-à-dire 0xC000, le début de la mémoire vidéo par défaut du CPC. L'adresse est donnée en décimal, car JSON n'a pas de notation hexadécimale pour les entiers, et le champ addr doit être un entier : une chaîne comme "0xC000" serait refusée.

Les paramètres optionnels exec et entry indiquent que l'on souhaite exécuter le code transféré, et à partir de quelle adresse. Ici, la séquence d'octets correspond à un petit programme qui change aléatoirement la couleur de la bordure, en boucle (un effet « raster ») :

LD A,R          ; ED 5F     : une valeur pseudo-aléatoire 
AND #1F         ; E6 1F     : on garde les 5 bits du code couleur
OR #40          ; F6 40     : on en fait une commande couleur
LD BC,#7F10     ; 01 10 7F  : port du Gate Array, stylo 16 (la bordure)
OUT (C),C       ; ED 49     : sélection du stylo 
OUT (C),A       ; ED 79     : envoi de la couleur
JR debut        ; 18 F1     : et on recommence

On a mis exec à true pour que le programme démarre dès que le transfert est terminé. Voici ce que ça donne :

Notez le petit segment de pixels colorés au-dessus du mot « Amstrad » : ce sont les octets de notre programme. Ils sont visibles, car on les a écrits au début de la mémoire vidéo.

Le paramètre bank est optionnel : il indique dans quelle banque physique de 16 Ko on souhaite écrire, de 0 à 3 pour les quatre banques qui composent les 64 Ko de base d'un CPC, 4 et au-delà pour les banques d'extension sur les machines qui en ont (128 Ko et plus). Les plus attentifs auront noté une petite subtilité : une adresse au-delà de 0x3FFF (16 Ko) déborde sur les banques suivantes. Comme 0xC000 vaut 3 × 0x4000, écrire à l'adresse 0xC000 depuis la banque 0 revient à écrire dans la banque physique 3, à l'offset 0. On aurait donc pu utiliser addr=0 et bank=3, mais partir de la banque 0 avec l'adresse « habituelle » est plus parlant.

Saine lecture

Même si le Curve Injector n'a pas besoin de lire la RAM, on va quand même détailler cet aspect de l'endpoint /api/ram. La lecture se fait avec un simple GET, cette fois sans JSON :

GET /api/ram?addr=0xC000&len=256&view=raw&bank=0

addr et len définissent sans surprise l'adresse et la longueur du bloc à lire. Cette fois, on peut donner l'adresse en hexadécimal, car il s'agit d'un paramètre de l'URL et non plus d'un champ JSON.

bank joue le même rôle qu'en écriture. view, en revanche, mérite un mot d'explication : le CPC sait basculer ses banques mémoire et superposer ses ROMs à la RAM, donc lire « l'adresse 0xC000 » peut avoir plusieurs significations tant qu'on n'a pas précisé à travers quel mapping on regarde. Trois vues sont disponibles :

• raw (par défaut) : le contenu brut de la banque demandée, sans tenir compte de la configuration mémoire du moment.
• cpu : la mémoire telle que le Z80 la voit à cet instant, avec les ROMs et les banques actuellement connectées. C'est la vue qu'on veut dès qu'on cherche à observer ce qu'exécute réellement un programme en cours, typiquement pour le déboguer.
• fw : la vue firmware, qui donne accès aux ROMs (la ROM basse et la ROM haute active).

Dans notre cas, adresser directement les banques avec raw est le plus adapté.

La réponse revient sous la forme d'une simple chaîne hexadécimale ({"hex": "004080c0..."}), deux caractères par octet, sans séparateur. Là encore, on peut vérifier rapidement dans le navigateur que ça fonctionne :

Si tu ne m'acquittes pas... tout peut s'oublier

On a vu qu'après une commande d'écriture, AMSpiriT répond immédiatement par {"ok":true,"seq":N}. Cette réponse est un simple accusé de réception : elle indique que l'écriture a été reçue et mise en file d'attente, pas qu'elle a déjà été appliquée. L'émulateur ne l'effectuera qu'au prochain tour de sa boucle principale.

C'est là que ram_apply_seq, croisé plus haut dans /api/ping, entre en jeu. Il suffit de le comparer au numéro N renvoyé dans le champ seq : dès que ram_apply_seq est supérieur ou égal à N, l'écriture a effectivement eu lieu.

Autrement dit : relire la RAM juste après avoir reçu {"ok":true,"seq":N} peut renvoyer l'ancien contenu, si on est plus rapide que la boucle principale. La bonne pratique est donc d'interroger /api/ping jusqu'à ce que ram_apply_seq atteigne N avant de faire confiance à une relecture :

# Écriture de 4 octets en 0xC000
$ curl -s -X POST http://127.0.0.1:6128/api/ram \
    -H "Content-Type: application/json" \
    -d '{"addr": 49152, "data": "ff00ff00"}'
=> {"ok":true,"seq":5}

# Vérification que l'écriture a eu lieu
$ curl -s http://127.0.0.1:6128/api/ping | grep -o '"ram_apply_seq":[0-9]*'
=> "ram_apply_seq":5

# C'est bon, on peut relire les données
$ curl -s "http://127.0.0.1:6128/api/ram?addr=0xC000&len=4&bank=0"
=> {"addr":49152,"len":4,"hex":"ff00ff00"}

Ici, ram_apply_seq vaut déjà 5 au moment du ping – la boucle a eu le temps de tourner entre les deux appels curl – et la relecture confirme bien les octets envoyés. Comme le compteur est global, il permet aussi de repérer si d'autres écritures ont été appliquées entre-temps : ram_apply_seq dépasse alors N.

La RAM vidéo fait des vagues

Bien ! Assez de théorie ! Il est temps d'utiliser notre outil, avec un premier exemple bête et méchant : injecter directement la courbe générée dans les 16 Ko de mémoire vidéo à partir de 0xC000. La longueur de l'injection monte ici à 16 384 octets : de quoi remplir l'écran entier avec le motif choisi, en une seule requête POST /api/ram. Une vidéo pour illustrer tout ça :

C'est un bon test de stress pour l'outil (16 Ko encodés en hexadécimal, ça fait 32 768 caractères dans le corps JSON), mais c'est surtout un exemple pédagogique : la relation entre la forme de la courbe éditée dans le navigateur et les octets qui atterrissent en mémoire vidéo est immédiatement visible à l'écran. Ce qui s'affiche, ce sont les octets bruts, interprétés à travers le codage des pixels propre au CPC.

Garder le cap

La vidéo en tête de l'article montrait une utilisation plus classique de l'outil : on injecte une table de valeurs à l'adresse exacte utilisée par le programme qui tourne, et on regarde l'effet réagir en temps réel pendant qu'on manipule l'amplitude, la période ou la phase depuis la page.

Dans ce cas, une courbe « brute » est rarement exploitable telle quelle : le programme qui lit la table attend des valeurs dans une plage précise, parfois avec certains bits imposés, et il ne s'agit pas de laisser une amplitude un peu trop généreuse écrire n'importe quoi en mémoire.

C'est pourquoi, une fois la courbe calculée, chaque échantillon passe par un encodeur avant d'être envoyé à /api/ram. C'est le rôle du panneau Output Encoding, dans son mode par défaut : le mode Data. Le panneau Output Preview, situé sous l'aperçu de la courbe, montre le résultat de ce filtrage : la courbe telle qu'elle sera réellement écrite en RAM,

Le pipeline est volontairement simple, et s'applique dans cet ordre :

1. Bornes : on fixe une valeur minimale et une valeur maximale. Ce qui dépasse est ramené dans la plage, selon l'un des deux modes proposés :
   • Saturate : la valeur est écrêtée sur la borne la plus proche. Une sinusoïde trop ample se retrouve « aplatie » en haut et en bas.
   • Modulo : la valeur « reboucle » à l'intérieur de la plage. Ce qui sort par le haut rentre par le bas, pratique pour un défilement ou un index qui doit tourner en boucle.
2. AND (optionnel) : un masque hexadécimal appliqué après les bornes, pour ne conserver que certains bits.
3. OR (optionnel) : un second masque, appliqué ensuite, pour forcer certains bits à 1.
4. Taille : chaque échantillon est enfin écrit sur 1 ou 2 octets. En 2 octets, les valeurs sont écrites en little-endian (octet de poids faible en premier), c'est-à-dire l'ordre natif du Z80 : un LD HL,(table) récupère directement la bonne valeur. C'est utile par exemple pour une table d'adresses écran ou de déplacements sur 16 bits.

La combinaison AND/OR est particulièrement pratique sur CPC, où l'on manipule souvent des octets dont une partie des bits a une signification fixe. Un exemple immédiat : on l'a vu avec notre petit programme raster, pour changer une couleur, on envoie au Gate Array un octet de la forme 010xxxxx, dont les 5 bits de poids faible sont le code couleur. Le programme faisait AND #1F puis OR #40 sur une valeur aléatoire. En appliquant les mêmes masques dans l'encodeur, n'importe quelle courbe produit à coup sûr une table de commandes couleur valides, directement utilisables par un OUT (C),A.

Cet exemple AND/OR produit des codes Gate Array valides, mais dans l'ordre des codes matériels, qui n'a aucun sens visuel : deux codes voisins peuvent donner des couleurs sans rapport. Pour obtenir de vrais dégradés, il faut aller un cran plus loin.

La courbe prend des couleurs

C'est ce qui a donné naissance au second mode d'encodage : faire en sorte que la courbe produise directement des couleurs, plutôt que des octets numériques « quelconques ».

Un petit rappel s'impose sur la façon dont le CPC gère ses couleurs, car elle diffère de la plupart des machines 8 bits de l'époque : pas de palette de teintes choisies une à une et figées dans le circuit vidéo, mais une vraie synthèse additive RVB, avec trois niveaux (0 %, 50 %, 100 %) sur chacune des composantes rouge, verte et bleue, soit 3³ = 27 couleurs possibles.

Chaque couleur possède un numéro BASIC (celui qu'on passe à INK, de 0 à 26, qui n'est qu'une décomposition en base 3 des trois composantes) et un code Gate Array correspondant : la valeur matérielle qu'un programme envoie réellement via OUT pour l'appliquer. Les deux ne se confondent pas : la correspondance entre eux n'est pas arithmétique, et sur les 32 valeurs que permettent les 5 bits du code Gate Array, 5 sont redondantes (la combinatoire RVB ne monte qu'à 27).

C'est tout l'objet du second mode du panneau Output Encoding : le mode Gate Array. Les masques disparaissent : la valeur de la courbe, toujours ramenée dans ses bornes par saturation ou modulo, désigne désormais une position dans un dégradé de couleurs. La couleur trouvée à cette position est ensuite convertie en son code Gate Array.

Plusieurs familles de dégradés sont proposées :

• les cercles chromatiques : teintes vives, pastel, sombres, ou l'ensemble du spectre,
• une rampe de luminosité traversant les 27 couleurs, du noir au blanc,
• une rampe par teinte (rouge, vert, bleu, cyan, magenta, jaune), du noir au blanc,
• pour les trois teintes primaires, une variante qui dérive vers une teinte voisine en montant en intensité : le rouge qui glisse vers l'orange puis le jaune est, sans surprise, la base d'un bon dégradé de flamme.

Les palettes sont définies dans de simples tableaux au début du script : il est facile de les modifier ou d'en ajouter à votre goût.

Comme en mode Data, le panneau Output Preview montre exactement ce qui sera écrit en RAM – mais cette fois sous la forme d'une frise des couleurs réelles, plutôt que d'une courbe numérique.

MIDI pile !

Dans certaines des vidéos, vous aurez remarqué que les paramètres de la courbe sont pilotés depuis un contrôleur MIDI physique. Rien d'exotique côté navigateur : le Curve Injector s'appuie simplement sur l'API Web MIDI, disponible nativement dans les navigateurs basés sur Chromium (Chrome, Edge...). Tout commence par une demande d'accès, qui déclenche une fenêtre de permission dans le navigateur :

navigator.requestMIDIAccess({sysex: false}).then(function(access) {
  access.inputs.forEach(function(input) {
    input.onmidimessage = onMidiMessage;
  });
});

Une fois l'accès accordé, chaque entrée MIDI détectée (access.inputs) se voit attribuer un gestionnaire onmidimessage. Chaque message arrive sous la forme d'un petit tableau d'octets (evt.data) qu'il faut décoder à la main – le standard MIDI n'a rien d'un JSON. Le Curve Injector ne s'intéresse qu'aux messages Control Change (CC), reconnaissables à leur premier octet :

function onMidiMessage(evt) {
  var data = evt.data;
  if (!data || data.length < 3) return;
  if ((data[0] & 0xF0) !== 0xB0) return;   // on ignore tout ce qui n'est pas un CC
  var channel = data[0] & 0x0F;             // canal MIDI, 0-15
  var cc      = data[1];                    // numéro de contrôleur, 0-127
  var value   = data[2];                    // valeur reçue, 0-127
  // ...
}

Vient ensuite le mécanisme d'apprentissage (« Learn ») : cliquer sur le bouton associé à un paramètre met l'outil en écoute, et le premier CC reçu sur n'importe quelle entrée est associé à ce paramètre. Plus besoin d'aller chercher dans la doc du contrôleur quel numéro de CC correspond à quel potentiomètre :

function captureLearn(deviceId, deviceName, channel, cc, value) {
  var m = midiMapping[learningParam];
  m.device  = deviceId;
  m.channel = channel;
  m.cc      = cc;
  // une valeur de 63 ou 65 trahit un encodeur relatif 
  // plutôt qu'un potard absolu
  m.type = (value === 63 || value === 65) ? 'relative' : 'absolute';
}

Cette dernière ligne mérite une explication : selon le contrôleur, un CC peut porter deux logiques différentes. Un potentiomètre ou un fader envoie une valeur absolue (0-127), qu'on met à l'échelle linéairement sur la plage du paramètre visé – y compris pour la forme d'onde, la plage 0-127 étant alors découpée en tranches égales, une par forme disponible. Un encodeur rotatif sans butée, lui, n'a pas de position absolue à transmettre : il envoie généralement 65 pour « +1 cran » et 63 pour « -1 cran », une valeur relative qu'il faut accumuler pas à pas plutôt que projeter directement :

if (m.type === 'relative') {
  var delta = (value === 65) ? 1 : (value === 63) ? -1 : 0;
  newVal = cur + delta * step;
} else {
  newVal = min + (value / 127) * (max - min);
}

Une fois la nouvelle valeur calculée, elle est appliquée au paramètre exactement comme si l'utilisateur avait déplacé le curseur à la souris : le CC MIDI n'est qu'une source d'événements de plus, au même titre qu'un input ou un change du DOM. C'est cette indifférence à la source qui fait que le reste de la chaîne (régénération de la courbe, encodage, envoi vers /api/ram) n'a rien à savoir du MIDI.

La chaîne complète, c'est donc : contrôleur MIDI → événement Web MIDI dans le navigateur → mise à jour du paramètre → régénération de la courbe → encodage → envoi via /api/ram → RAM émulée → rendu à l'écran.

C'est exactement le genre d'assemblage improbable-mais-évident que permet une API HTTP simple sur un émulateur : le contrôleur MIDI, le navigateur et l'émulateur ont été conçus indépendamment, mais ils s'interfacent simplement, et peuvent travailler ensemble.

Voila! J'espere que ce petit article vous aura donné des idées. Le Curve Injector est disponible sur le dépôt amspirit-releases. Comme toujours, prenez-le en main, bidouillez-le, faites-en quelque chose d'utile pour vous, et n’hésitez pas a le partager!

Siko / Logon System
Septembre 2026

🇬🇧 English version

Quelques mois après la sortie de la première version d'AMSpiriT Lite, il est temps de faire un premier bilan et de partager un état des lieux du travail accompli, et de ce qu'il a à offrir. Comme on le verra dans cet article introductif, il ne s'agit pas d'un simple portage sur les plateformes (Linux, macOS (Silicon), RPi5...) mais aussi une tentative d'explorer de nouvelles pistes et de proposer des outils encore peu répandus dans le monde de l'émulation CPC. L'objectif n'était pas d'ajouter un énième émulateur à une liste qui ne cesse de s'allonger!

Cet article présente donc AMSpiriT Lite dans les grandes lignes : ce que c'est, quels sont ses atouts, ce qu'il propose en termes d'outillage, et quelques réalisations construites avec lui. Une partie des exemples présentés ici sont disponibles sur le site amspirit.fr et sur les divers dépôts GitHub.

Je voudrais remercier non seulement l'équipe de développement derrière AMSpiriT - Dmanu78, Longshot, Gurneyh, Tronic - mais aussi l'équipe impitoyable de testeurs : Ricolaoz, Lord Heavy, Fred, Ldir Hector. Merci du soutien que certains d'entre vous nous ont manifesté, merci à ceux qui ont fait l'effort d'essayer nos outils et d'adapter les leurs pour développer leurs projets : c'est fort appréciable et ça aide à garder la motivation pour continuer !

AMSpiriT Lite : qu'est-ce que c'est vraiment ?

Commençons par clarifier une chose : il existe deux versions de l'émulateur AMSpiriT. La première, AMSpiriT 'original', créé sur Windows par DManu78, demeure l'implémentation de référence. La seconde, AMSpiriT Lite, est née de la volonté de porter l'émulateur sur d'autres systèmes d'exploitation. L'interface utilisateur de la version originale reposant sur des bibliothèques Windows, l'idée a été de repartir du même cœur d'émulation, mais de recréer intégralement l'interface, cette fois-ci autour de bibliothèques portables.

Cela a donné naissance à plusieurs moutures : l'une basée sur Qt, avec menus déroulants et fenêtres de réglages classiques ; l'autre basée sur SDL, épurée, quasiment sans interface, plus légère et plus simple à porter.

AMSpiriT Lite ne réplique donc pas fidèlement l'original au niveau de l'interface. Il en conserve le cœur - le moteur d'émulation - mais lui applique une philosophie différente, en mettant l'accent sur la simplicité, la compatibilité et la flexibilité, comme on va le voir.

Le cœur : identique et portable

Les deux versions partagent la même mécanique d'émulation : le processeur Z80, la Gate Array, le PSG, le FDC (contrôleur de disquette). Tout est implémenté dans le cœur de l'émulateur écrit par DManu78, en C++ moderne et portable.

Le core n'a aucune dépendance graphique, ni sonore, ni vers un système d'exploitation particulier. Dans le jargon, on dit qu'il est headless : c'est une boîte noire qui reçoit l'état d'entrée et renvoie les pixels et les samples à chaque image (50 Hz). Tout ce qui tourne autour - la fenêtre, les menus, le clavier, le son - relève de l'enrobage, et c'est là que Lite et l'original divergent.

Cela signifie qu'une correction ou une optimisation apportée au core bénéficie immédiatement aux deux versions. Inversement, certaines expérimentations menées dans Lite pourront remonter dans l'original si elles se révèlent utiles.

L'enrobage : simplifié et expérimental

AMSpiriT original offre une interface graphique riche : des options nombreuses, toutes accessibles via des boîtes de dialogue ou des menus.

AMSpiriT Lite prend l'approche inverse. Son enrobage est minimaliste : peu de configuration au runtime, peu de menus et de dialogues. Avec cette version, on colle au modèle des ordinateurs d'époque : on allume la machine, on insère une disquette ou une cartouche, on lance le programme, et c'est tout.

Cette philosophie rend Lite légère, rapide à initialiser et simple à tester et à enrichir. C'est le terrain qui nous a permis d'expérimenter de nouvelles fonctionnalités : ajouter un serveur web HTTP pour piloter l'émulateur, intégrer un moteur de script Lua, construire une extension VS Code qui injecte du BASIC directement en RAM.

Cela ne rend pas pour autant la version originale obsolète, bien au contraire. Celle-ci reste plus complète, et surtout la nouvelle version en cours de développement va offrir un environnement de développement rare dans le monde de l'émulation CPC : un véritable IDE, très poussé dans ce qu'il offre comme accès aux entrailles du CPC et comme options de débogage, avec une ergonomie pensée par et pour des développeurs.

Les saveurs

AMSpiriT Lite existe en deux variantes principales, chacune avec un équilibre différent entre minimalisme et ergonomie.

1. SDL2 : la version légère et portable

C'est la version la plus portable et la plus dépouillée. Elle utilise la SDL, une bibliothèque graphique minimaliste, et crée une fenêtre 1024 × 540 à 50 Hz - c'est à peu près tout. Pas d'interface utilisateur intégrée au-delà du clavier et de l'écran, un OSD réduit au strict minimum, et aucun menu à la souris.

Pour lancer un programme, il suffit de faire un glisser-déposer d'un fichier (.dsk, .cpr, .sna, ou même un listing basic en .bas) sur la fenêtre, puis de taper des commandes au clavier du CPC comme si on faisait fonctionner une vraie machine des années 1980. De nombreuses options en ligne de commande permettent par ailleurs de piloter l'émulateur et de réaliser les mêmes opérations.

Quand l'utiliser : développement de programmes CPC, débogage, test, ou simplement par goût des interfaces épurées. Elle a été créée initialement pour faciliter le portage sur différentes plateformes, mais elle se suffit à elle-même. Très légère (quelques mégaoctets), elle démarre rapidement.

2. Qt : la version ergonomique

C'est la réponse à ceux qui trouvent SDL un peu trop spartiate. Qt offre une interface de bureau classique : menus, boutons, boîtes de dialogue.

En plus des fonctionnalités de la version SDL (glisser-déposer), on peut sélectionner un fichier via une fenêtre de dialogue, ajuster le volume avec une barre glissante et consulter l'état de la disquette en temps réel. On a également accès à une liste de commandes rapides. Bref, une application dans les canons standards.

Sous le capot, Qt communique toujours avec le même cœur d'émulation : les performances et la précision sont identiques.

Quand l'utiliser : si l'on préfère une expérience graphique plus classique. C'est probablement la meilleure porte d'entrée, et c'est clairement la version qui a eu le plus de succès pour le moment.

3. D'autres variantes

Il existe en réalité d'autres moutures d'AMSpiriT Lite : une version SDL + ImGui, une version headless, et même un core RetroArch :

• SDL + ImGui - la même base SDL2, augmentée d'une interface overlay dessinée à même la fenêtre. Expérimentale, elle cherche le compromis entre la légèreté de SDL et le confort de Qt.
• Headless - aucune fenêtre, aucun son, aucune entrée clavier. L'émulateur ne s'y pilote que par l'API web et par des scripts. C'est la variante des tests automatisés et de l'intégration continue : on la lance, on lui parle en HTTP, on lit les résultats.
• RetroArch - un core Libretro : une bibliothèque partagée (.so sur Linux) qui s'intègre dans RetroArch, le frontend qui unifie des centaines d'émulateurs sous une seule interface. On lance RetroArch, on sélectionne le core AMSpiriT Lite, on charge un fichier CPC, et c'est parti. RetroArch gère la fenêtre, les contrôles, la sauvegarde d'état, les shaders et tout le reste ; le core n'a qu'une chose à faire : émuler. C'est la solution la plus intégrée pour qui joue déjà à des jeux rétro via RetroArch. Mais c'est aussi la plus fermée : pas d'accès direct à la ligne de commande du CPC, pas de serveur web, juste le jeu.

Les « petits » plus

Une API

Il a été dit plus haut qu'il n'y avait pas d'interface intégrée dans la version SDL2. C'est vrai, mais il existe en fait une interface encore rare dans le monde de l'émulation CPC (même s'il semble que l'idée fasse des émules !) : une API web. Il suffit de choisir un port et de lancer l'application avec les options --web-server (pour activer le serveur) et --web-port. Il est aussi possible de choisir l'interface réseau avec --web-addr ; ce dernier paramètre est important si l'on veut rendre l'émulateur accessible sur le réseau local, car par défaut c'est localhost qui est utilisé. Par exemple, avec --web-server --web-addr 0.0.0.0 --web-port 6128, l'API sera accessible sur toutes les interfaces de la machine hôte, via le port 6128. Bien sûr, si plusieurs instances tournent en parallèle, chacune devra avoir un port différent.

Mais pour quoi faire ?

L'API permet de piloter l'émulateur et le CPC émulé à travers toute une série d'endpoints, qui vont du contrôle de l'émulateur (start/stop, reset, pause…) jusqu'au contrôle du CPC lui-même : accès en lecture/écriture à la RAM, frappe de touche sur le clavier, etc.

Pour tester l'API, rien de plus simple : une commande curl suffit. Par exemple, pour récupérer des données en RAM - ici 32 octets à partir de l'adresse 0x4000 :

curl -s 'http://127.0.0.1:6128/api/ram?addr=0x4000&len=32'

Et cerise sur le gâteau : une page web intégrée à l'application, et personnalisable, donne déjà accès à plusieurs fonctionnalités de l'API - clavier virtuel, dump de la RAM, débogueur BASIC, etc. Cette interface est disponible dans toutes les versions de l'émulateur.

Le prochain article rentrera dans les détails de l'API ; c'est assez copieux, et j'espère que ce ne sera pas indigeste ! En attendant, il existe une documentation détaillée et des pages de test pour comprendre rapidement le fonctionnement de l'API. Les ressources ne manquent pas.

Des outils pour le BASIC

Autre ajout très pratique : la possibilité de transférer un programme BASIC et de l'exécuter par un simple glisser-déposer. AMSpiriT Lite intègre en effet un tokenizer BASIC très rapide. Plus besoin des autotypes, qui mettent un temps fou à transférer un programme : c'est le PC qui se charge de transformer le BASIC de sa forme texte vers la forme manipulée par le firmware, le transfert est ensuite instantané. Et ce transfert peut aussi se faire via l'API web :

curl -X POST 'http://127.0.0.1:6128/api/basic?run=1' \
     -H 'Content-Type: text/plain' \
     --data-binary $'10 PRINT "BONJOUR"\n20 GOTO 10'

Le transfert fonctionne aussi dans l'autre sens, pour récupérer rapidement le listing d'un programme chargé en RAM.

L'interface web permet également d'écrire du BASIC, de le transférer, de poser des points d'arrêt (sur une ligne ou même sur une instruction) et de consulter l'état des variables :

Du script Lua

Et ce n'est pas tout : AMSpiriT Lite permet - comme la version originale - d'exécuter des scripts CSL, mais pousse un peu plus loin en proposant une intégration Lua, qui offre les mêmes possibilités que le CSL avec toute la puissance d'expression du langage Lua. Pour rappel, Lua est un langage de script léger, rapide et extensible, principalement conçu pour être embarqué au sein d'autres applications. Il est particulièrement populaire dans le développement de jeux vidéo, où il a notamment permis de créer de nombreux « mods ».

La page web intégrée contient d'ailleurs une console Lua interactive, qui permet de tester rapidement une fonction ou un script, avec un rappel de tous les appels possibles - les fonctionnalités de l'API web étant directement accessibles.

Timelapse et débogage à la relecture

AMSpiriT Lite embarque aussi un système de timelapse - une fonctionnalité de pause et de relecture inspirée des pratiques des émulateurs modernes. L'idée est simple, mais très efficace pour le débogage : on peut mettre l'émulateur en pause, puis reculer dans le temps pour revoir ce qui s'est passé, image par image.

Comment ça marche : quand l'émulateur est en pause, les touches du clavier (ou directement la manette de jeu) permettent de :

• revenir en arrière (comme avec un magnétoscope), puis revenir au « présent » ;
• relancer la lecture depuis n'importe quel point ;
• reprendre ou mettre en pause ;
• avancer image par image lorsqu'on est au présent.

C'est particulièrement utile pour déboguer un jeu ou un programme : on observe un bug, on met en pause, et on peut reculer pour voir exactement ce qui a précédé le problème. Pas besoin de relancer depuis le début à chaque fois. L'avance image par image permet de bien décomposer ce qui se passe à l'écran.

Pour le jeu, le pilotage à la manette est appréciable : le retour en arrière se fait sans avoir à la lâcher.

Les slots de sauvegarde d'état

En complément du timelapse, AMSpiriT Lite dispose d'un système de slots, à la manière de RetroArch. C'est un mécanisme qui permet de sauvegarder l'état complet de la machine à un instant T et de recharger cet état sur demande, le tout à la manette.

Comment ça fonctionne : plusieurs slots sont disponibles, et permettent de :

• sauvegarder l'état courant dans un slot (par exemple avant un moment critique du jeu)
• recharger cet état plus tard (en cas d'échec, on revient exactement au point de sauvegarde)
• changer de slot pour disposer de plusieurs points de sauvegarde

Un court retour visuel confirme que la sauvegarde ou le chargement a eu lieu.
À noter que les slots sont associés au nom de la disquette (ou du support) inséré : en reprenant une partie plus tard, les sauvegardes correspondantes sont directement accessibles.

En résumé, ces deux fonctionnalités - timelapse et slots - font d'AMSpiriT Lite un outil commode pour :

• déboguer des programmes
• progresser dans les jeux et conserver sa progression
• documenter et analyser le comportement des programmes

Tout cela en fait un outil adapté à l'automatisation, aux tests de non-régression et au développement, d'autant plus qu'il repose sur un cœur d'émulation très fidèle au matériel original - c'est le crédo fondateur d'AMSpiriT : « Accuracy without compromise ». Sans cette fidélité, ce qui est observé dans l'émulateur n'aurait pas grand sens sur la machine réelle.

Des exemples de réalisations

Maintenant qu'on a fait un tour d'horizon des principales fonctionnalités apportées à l'émulateur, je voudrais terminer par la question la plus intéressante : on construit quoi avec ça ? Pour donner une idée des possibilités, voici quelques exemples d'applications ou d'outils réalisés avec cette API. Comme on va le voir, depuis quelques mois l'API a été prise en main par des développeurs CPC, et des interfaces comme des outils ont été créés, des plus génériques aux plus spécifiques.

La carte d'un jeu, sans y jouer

Knight Lore reste parmi ces jeux qui n'ont cessé de m'émerveiller. Rendez-vous compte : un jeu de 1984 qui intègre un rendu isométrique, un moteur physique, des énigmes qui exploitent cette physique, des pièges et des ennemis aux comportements variés, un cycle jour/nuit et un vaste monde de 128 pièces.

L'une des premières applications que j'ai pu faire avec l'API d'AMSpiriT, c'est de reconstituer automatiquement la carte du monde de Knight Lore. Je n'ai pas eu à reparcourir chaque salle du jeu pour l'obtenir (le jeu est bien difficile !) : j'ai écrit un script qui téléporte le héros de pièce en pièce, capture chaque écran à l'instant précis où le décor vient d'être chargé, puis recolle les 128 pièces en une seule image. Voici le résultat :

Pour que l'image obtenue soit lisible, le script retire tous les murs de la pièce ainsi que le personnage à chaque changement de salle. C'est possible en posant un point d'arrêt juste après la routine de chargement de pièce du jeu, pour injecter du code qui va filtrer les données de la pièce.

J'ai entrepris le désassemblage complet du jeu, ce qui permet de récupérer tous les graphismes en exploitant un dump de la mémoire. Voici les 103 sprites du jeu, étiquetés de leur adresse en mémoire. J'en reparlerai probablement plus en détail ultérieurement, et le code sera publié prochainement pour les plus curieux.

Chercher des vies infinies

ram-search est un exemple que j'affectionne particulièrement, parce qu'il est minuscule : un fichier HTML de 446 lignes, du JavaScript natif, aucune dépendance, aucune étape de compilation. On l'ouvre directement dans le navigateur, en local, depuis le disque - file:// fonctionne - et il pilote l'émulateur. C'est une façon très concrète de montrer ce que permet une API ouverte en CORS : une page tierce, posée n'importe où, devient un outil d'analyse.

La méthode employée est le classique rétrécissement par instantanés successifs, bien connu des utilisateurs de Cheat Engine. Le nom fait un peu pompeux, mais c'est très simple : chaque passe fait un seul appel à l'API, GET /api/ram?addr=0&len=65536. On récupère ainsi un instantané des 64 Ko de la RAM, d'un coup. On le compare à l'instantané précédent et on ne garde que les adresses qui correspondent à un filtre.

Concrètement, on joue entre deux passes, on indique ce qui vient de se produire (« la valeur a diminué », « elle n'a pas changé », « elle vaut exactement 3 »), et la liste de candidats diminue par élimination.

Quand il ne reste qu'une adresse, deux boutons : écrire une valeur ou, plus radical encore, la geler. Dans l'implémentation, ce dernier cas consiste à réécrire la même valeur toutes les 150 millisecondes. Des vies infinies en une ligne de code.

Quelques détails d'ergonomie : le premier filtre utilise /api/screenshot et intègre une capture de l'écran de l'émulateur dans la page. Le second est un mode « valeurs en direct », qui permet d'observer l'évolution des candidats. Et surtout, de nombreux filtres sont disponibles, car on ne dispose pas toujours de la valeur exacte : dans le cas d'une barre de vie, par exemple, on ne sait pas forcément comment la valeur est codée. On peut alors se contenter de surveiller les valeurs qui changent, à la baisse par exemple.

Voir l'activité en mémoire

La première fois que j'ai vu une carte dynamique montrant l'activité de la RAM en direct (lectures/écritures), c'était avec un émulateur que j'affectionne particulièrement : tiny8bit. Son auteur fourmille d'idées qu'il partage sur son blog et propose de très bonnes visualisations du fonctionnement d'un processeur comme le Z80. Dès que l'API a été mise au point, l'une des premières choses que j'ai codées, c'est cette « heat map », disponible dans la page web intégrée :

L'onglet Heat Map de l'interface web dessine des blocs mémoire de 64 Ko sur un carré de 256 × 256 : un pixel par octet, l'axe vertical pour l'octet haut de l'adresse, l'horizontal pour l'octet bas. Chaque écriture réchauffe son pixel, qui refroidit progressivement. Cette vue montre donc l'activité récente en mémoire, avec une décroissance réglable, et les couleurs permettent de distinguer les modifications récentes des plus anciennes.

Le résultat est étonnamment parlant. On voit la mémoire écran se remplir à chaque image, les tampons de travail d'un jeu pulser en rythme, les variables du BASIC vivre dans leur petit coin. Et surtout, on repère instantanément où un programme écrit vraiment - une information qu'on mettrait longtemps à extraire d'un désassemblage. Dans la capture ci-dessus, on distingue en gris le buffer de rendu intermédiaire vers le centre de l'image, ce qui est typique d'un portage depuis le Spectrum ; les zones colorées, elles, correspondent aux éléments qui bougent à l'écran.

Techniquement, ce n'est qu'un sondage en boucle de GET /api/ram - la démonstration qu'un endpoint banal, plus une bonne visualisation, donne un outil d'analyse.

Et plus encore

Ce ne sont là que quelques exemples de réalisations construites autour de l'API. Par exemple, cet outil sur mesure que Fred s'est créé pour mettre au point le remaster de son jeu Fugitif 31 qu'il avait publié chez Lankhor au début des années 90. Cet outil lui permet par exemple de voir toutes les variables internes de son moteur:

Ici, il a opté pour une interface en python. J'aurais pu évoquer les plugins VS Code que Gurneyh a écrits pour se faire un éditeur assembleur/débogueur intégré, ou un éditeur BASIC, ou encore des outils en Python pour assister au désassemblage et à l'analyse du code ; j'en reparlerai sûrement dans d'autres articles.

C'est Astra

Car alors que j'étais en train de boucler ce billet, un nouveau modèle de LLM est sorti, disponible pour le grand public: Astra de chez OpenAi. Tronic, qui a eu envie de l'évaluer, lui a donné accès au contrôle d'AMSpiriT via l'API et lui a fourni de la documentation, en particulier le compendium CRTC. Si certains ont pu trouver la lecture de ce document ardue, l'IA n'a pas eu de difficulté à le digérer et, correctement guidée, à produire des choses assez épatantes, il faut le reconnaître. Tronic a ainsi réussi à obtenir des effets considérés comme parmi les plus complexes que l'on puisse faire sur CPC, comme des ruptures verticales - des techniques qui requièrent une synchronisation parfaite des instructions envoyées au CRTC, le tout en plein écran:

En analysant le code, on a pu voir que le LLM avait opté pour des stratégies différentes selon la complexité de l'effet: de la RVI pour les cas complexes, (1ere et 3eme vidép qui nécessitent une gestion verticale) et RFD pour la simple gestion horizontale (video 2).

Ces techniques sont décrites dans le Compendium, mais jusqu'à présent aucune IA n'avait réussi à les mettre en œuvre. Pour y parvenir, elle a pu expérimenter avec l'émulateur, faire des essais, adapter son code. Et c'est là que la fidélité de l'émulation est cruciale : si l'émulateur n'est pas assez précis, l'IA en exploitera les approximations et produira du code qui ne tournera pas sur le vrai matériel.

Dans un registre plus ludique, Tronic a aussi co-développé des preuves de concept de jeux, et le résultat est encourageant. En ajoutant des assets et des captures d'écran dans sa marmite, il a pu obtenir rapidement des premiers jets de jeux proches de Donkey Kong, Barbarian ou Out Run, ainsi qu'un Bomb Jack pour CPC+ dont le premier niveau est tout à fait jouable.

Quelques perspectives

Sous le capot, si on regarde bien, la plupart des exemples cités reposent sur les deux mêmes endpoints : /api/ram et /api/screenshot. Ce qui change, c'est l'usage qu'on en fait : comparer deux dumps donne un mini « Cheat Engine » pour trouver les vies infinies dans un jeu, les colorier donne une carte de chaleur, les recoller donne la carte d'un jeu ou des planches de sprites. L'API est petite, la combinatoire ne l'est pas. Et c'est l'essence même de la philosophie derrière AMSpiriT Lite : apporter des briques pour que chacun puisse se faire ses propres outils, intégrer l'émulateur dans sa propre chaîne de développement, et créer tout ce qui nécessite un émulateur pilotable. L'arrivée de l'IA ouvre par ailleurs des perspectives vertigineuses : avec ces deux points d'entrée, un LLM est capable de piloter l'émulateur, de voir le résultat visuel obtenu et, par itération, d'écrire du code de plus en plus sophistiqué.

Ces derniers exemples, produits avec de l'IA, ne sont certes pas aboutis ni finalisés : ce ne sont pas des jeux complets, et il ne faut pas les prendre pour autre chose. Mais ce sont les marqueurs d'une évolution que l'on est en train de vivre.

Cela annonce probablement une nouvelle génération de jeux, en quantité. Tout ne sera pas bon, c'est certain, mais le ticket d'entrée pour réaliser des productions de plus en plus léchées ne cesse de diminuer. Et si, avec AMSpiriT, nous pouvons apporter notre pierre à l'édifice, alors nos efforts n'auront pas été vains.

Et l'émulation ?

Il y a une dernière catégorie de réalisations que je n'ai pas citée : les émulateurs eux-mêmes. Ces dernières années, et ces derniers mois en particulier, on a vu apparaître beaucoup d'émulateurs Amstrad CPC, de plus en plus performants. Nous sommes en contact avec plusieurs de leurs auteurs, et ceux qui ont l'amabilité de citer leurs sources mentionnent le Compendium CRTC, la suite de tests Shaker, et maintenant AMSpiriT, qui sert de "source de vérité". AMSpiriT est désormais utilisé pour fournir les images de référence issues de Shaker, que l'on retrouve sur Shakerland. Ces images peuvent servir à comparer les sorties d'un émulateur et ainsi à valider la progression de l'émulation. Si AMSpiriT peut aussi aider les développeurs d'émulateurs et de hardware, ce sera une victoire de plus pour nous.

La suite de cette série

Avec ce premier article introductif, vous savez désormais ce qu'est AMSpiriT Lite : un cœur d'émulation solide, enrobé de façons expérimentales. Les articles suivants rentreront plus en profondeur dans l'API et les outils livrés avec AMSpiriT Lite, et vous montreront comment en tirer le maximum :

• L'API web - se connecter, charger un média, piloter la machine, s'abonner aux événements…
• Le BASIC - glisser-déposer un .bas, et le débogueur BASIC de l'interface web : points d'arrêt, variables, pas-à-pas.
• Lua et scripting - la console interactive, l'automatisation, les tests de non-régression.
• VS Code et outils externes - plugin d'éditeur, CI/CD, intégration dans vos workflows.
• Des exemples d'application.

Chaque article est une fenêtre vers les possibilités offertes par AMSpiriT Lite. J'espère qu'elles vous inspireront des idées d'outils et d'interfaçages : c'est pour cela que nous avons développé et ouvert cet outil. Avec le reste de l'équipe, nous vous invitons à explorer, à contribuer et à nous envoyer vos retours. AMSpiriT Lite grandit avec ses utilisateurs ! N'hésitez pas à partager vos réalisations, sur les réseaux sociaux ou sur Discord : nous nous ferons un plaisir de les relayer et, si besoin, de vous accompagner.

Siko / Logon System, Septembre 2026

🇬🇧 English version

Cela faisait un moment que je n’avais par écrit sur ce blog.

La publication récente de nos travaux et du format musical AYT est donc une excellente occasion de m’y remettre.

Click here for english version 🇬🇧 https://blog.logonsystem.eu/welcome-to-ayters-eng/

AYT Sound Format by GPA & Logon System

demotool for Linux / Windows / Amstrad CPC / ZX Spectrum / JavaScript / MSX / Amstrad Plus / MacOSX Intel, released in october 2025

pouët.net2025-10-29 08:51:39

Qu’est ce que le format AYT  ?

AYT (AY Turbo) est un format de fichier musical qui a été conçu pour les puces sonores AY-3-8910/2 de Général Instrument et Yamaha YM2149. Il  est généré à partir du format YM, créé originellement par Léonard à partir de données à l'origine sur ATARI ST. Le format YM représente le contenu brut de toutes les valeurs envoyées au circuit.

Le format AYT  propose une nouvelle approche de « compression » dans l’objectif d’obtenir une restitution très rapide et en temps constant du code qui joue une musique pour des plateformes antérieures à l’ATARI ST, et disposant de moins de ressources CPU et de mémoire.

D’autres formats musicaux existent déjà!

Alors qu’est ce qui distingue ce nouveau format  des autres déjà disponibles ?

Je vais essayer de répondre à cette question dans ce billet.

Et pour ça, il faut aborder avant....

La compression de données

La compression de données est née du besoin de réduire la quantité d’informations stockées ou transmises, dans un contexte où les ressources étaient limitées : mémoire coûteuse, bandes passantes réduites, supports lents. Les premiers travaux théoriques — Shannon, Huffman, Lempel et Ziv — ont jeté les fondations permettant de transformer de longues séquences redondantes en représentations plus compactes.

Au fil des décennies, les méthodes se sont diversifiées : compression statistique, dictionnaires adaptatifs, transformées, entropie, delta-encoding, run-length, etc. Chaque approche répond à un compromis différent entre efficacité, rapidité, universalité et coût de mise en œuvre.

Cependant, la compression introduit une opposition fondamentale :

Pour les systèmes modernes, ce compromis est aujourd’hui souvent masqué par l’augmentation constante de la puissance matérielle. Quelques millisecondes de décompression sont presque indétectables pour un ordinateur contemporain.

Pourtant, ce dilemme demeure très concret pour la communauté travaillant avec des ordinateurs rétro, particulièrement ceux dont la mémoire et le processeur sont extrêmement limités, comme l’Amstrad CPC. Sur ces machines, décompresser un format complexe peut avoir un coût prohibitif : cycles CPU perdus, difficultés à tenir un timing fixe, tenter de partager la CPU entre l’envoi au circuit sonore et la décompression...

La corrélation entre taux de compression élevé et vitesse de traitement lente reste donc un enjeu majeur dans ce domaine.

Réduire la taille d'un fichier YM

Le YM est simple mais volumineux car il stocke les registres du circuit à chaque frame. Une grande majorité des approches précédentes consistait à utiliser la très bonne capacité de ce fichier à être compressé par des algorithmes récents, optimisés et très performants.

Malgré ces performances, la décompression a un coût CPU. Sur Amstrad CPC ou ZX Spectum, cette ressource CPU est devenue précieuse car les programmes sont de plus en plus optimisés et profitent de chaque cycle libre. Sans modifier totalement l’identité d’une machine, vouloir accélérer un ancien processeur relève davantage de l’expérimentation personnelle  en électronique et présente souvent peu d’intérêt pour une majorité de personnes au sein de ces communautés.

En revanche, la mémoire, qui pouvait déjà à l’époque être étendue avec des extensions hors de prix, peuvent aujourd’hui bénéficier de nombreux projets qui ont permis d’étendre les limites de la ram et de rom disponibles de base sur les machines, ou même encore les espaces disques disponibles (adoption par exemple de formats de disquettes double piste, double tête).

Si je vous parle de CPU et de mémoire, c’est que contrairement aux approches visant une compression maximale du format YM (le format brut non compressé des registres de la puce), AYT a choisi un chemin différent, en misant sur la simplicité et la structure originelle des données musicales.

Le format AYT n’essaie pas d’atteindre un ratio de compression extrême et tente de « retrouver » l’organisation interne des données telles qu’elles sont produites par les outils de compositions (trackers, séquenceurs YM). Cela permet de garder une logique de vectorisation de « motifs » (appelés « Pattern » dans le jargon musical) accessibles et directement exploitables.

Le format AYT prend donc le contrepied des logiques précédentes :
il propose une compression légère, mais se base directement sur la structure d’origine des données telles qu’elles sont organisées dans les outils de création musicale.

L’objectif n'est pas de compresser au maximum, mais de représenter efficacement et proprement l’intention musicale, tout en garantissant des performances déterministes.

Bien sûr, c’est une idée qui a traversé la tête de très nombreuses personnes, mais encore fallait il avoir la motivation et le temps de travailler sur ce sujet et de l’avancer à ce stade...

La génèse du projet AYT

Si Candy avait travaillé sur ce sujet, comme moi-même bien des années auparavant, c’est la collusion des élucubrations de ce dernier, croisée avec la motivation altruiste de Tronic, qui a conduit ce dernier à construire les premières versions d’un format exploitable.

Tronic s’est  « amusé » à prendre des séries de sorties du Loto pour voir combien de fois elles apparaissaient dans l’historique complet des tirages. Une fois devenu immensément riche, tel Emmett Brown découvrant le convecteur temporel, l’idée lui est venue de pousser cette idée et de l'appliquer à quelque chose de réellement utile cette fois ci: calculer combien de patterns uniques de taille T on pouvait dégager d’un registre AY.

Je ne dirai rien sur la gueule des premiers formats qu'il m'a montré, mais l’affaire était lancée, et nous avons tous apporté des idées pour faire avancer positivement les choses. Siko rejoignant alors Tronic dans une course folle à la vectorisation des patterns, à base de terminologies barbares (principe du recuit, algorithmes génétiques, le petit glouton...). Il vous en dira certainement bien plus que moi avec ses propres mots prochainement.

Une particularité intéressante de ce projet, c’est qu’il est possible de gagner en compression sans avoir à retoucher au Player, ce qui nous a permis d'avancer bien plus vite. C’est d'ailleurs encore ce que continue à faire Siko et à l’heure ou j’écris ce billet. Ses derniers résultats sont d'ailleurs étonnants au niveau de la taille gagnée. Le moins qu’on puisse dire donc, c’est qu’ils ont tous les deux avancé tous azimuts, chacun dans un style propre.

Tronic en mode fusée intersidérale et Siko en mode ultra-pondéré.

De mon côté, j’ai ajouté quelques spécifications au format, pour définir le contenu du header ou les séquences additionnelles ou d’initialisation, organisées pour que leur traitement soit le plus simple et efficace possible.

Je souhaitais que la facilité d’utilisation soit un des points forts de ce format, et nous avons oeuvré pour que cela le soit, et que l'information soit la mieux partagée possible. Nos travaux sont ainsi disponible en libre service ici:

Logon System

Logon System has 2 repositories available. Follow their code on GitHub.

GitHub

Pour l’anecdote, en 2021, j’ai eu besoin d’un player temps fixe, et n'en trouvant pas, je n’ai pas eu d’autre choix à l’époque que d’adapter en temps fixe le player AYC très performant écrit par Madram et Shap [Si le sujet du temps fixe vous intéresse, j’ai écrit quelques chapitres sur le sujet, que vous pouvez lire au chapitre 24 du Compendium 1.8].

J’avais largement commenté ce source du player pour en faciliter l’utilisation et je l’avais distribué au sein de la "communauté Cpc". Malheureusement, malgré cette initiative de partage, son usage a trouvé peu d’écho auprès des personnes qui ont eu besoin de player après. Peut-être à cause de la complexité de génération de fichiers AYC ou de l’utilisation même du player, ou encore une mauvaise distribution. Il est resté jusqu'en juin 2025 le player temps fixe public le plus rapide sur CPC, mais je n’étais pas allé le clamer sur le portail Pouet.

Il me semblait nécessaire que le format AYT dispose d’une meilleure visibilité auprès de la communauté, et surtout qu’il soit bien plus simple à utiliser que le player AYC "temps fixe" délaissé ou les autres formats.

Cette simplicité passait naturellement par un changement conceptuel de gestion du player. Au lieu de fournir une « routine » classique transformée de manière alambiquée par un code d'initialisation, la nouvelle idée consiste à fournir un code capable de générer lui-même l'intégralité du code du player, tel que le ferait un compilateur. J’ai appelé ce code un « builder » (constructeur) et il a grandement simplifié le processus d’utilisation sur la plateforme.

En partant de ce principe, et pour les personnes qui travaillent en cross dev, il est d'ailleurs possible d’imaginer que le « builder » soit adapté en C sur la plateforme de développement pour fournir le code, voir directement le source du player intégrable dans une chaine de compilation.

Mes deux compères m’ont suivi sur cette voie de leur côté en créant des outils de plus en plus puissants et faciles à utiliser. Cela s’est traduit concrètement par des outils directement disponibles sur le web et simplifiant grandement des sujets tels que les conversions, l'écoute, le séquencage, ou même les conversions de fréquences puisqu'il est nécessaire d’adapter les données en fonction de la vitesse ou le circuit est cadencé sur la plateforme cible et en fonction de celle qu’il avait sur la plateforme d’origine.

La taille d'un fichier AYT

Si la taille d’un fichier AYT n’est pas son meilleur atout par rapport à un format ultra compressé, il faut aussi retenir que la taille du fichier est très dépendante de l’origine des données de base, afin d'éviter toute généralisation abusive.

Un fichier issu de certains trackers pourra donc donner de très mauvais résultats, et l’inverse avec des fichiers provenant d’autres outils, ou sur des musiques courtes. Il existe par exemple énormément de musiques réalisées sur d’autres plateformes que le CPC.

Sur ZX Spectrum, qui dispose de la plus vaste collection de musique AY existante, 83% des musiques AYT converties à partir du format PT3 existantes ont une taille inférieure à 17k. Plus de 100 000 musiques en AYT ont actuellement été transformées à partir de très nombreux formats et chipsets sonores, ce qui a permit de consituer une base statistique intéressante.

Enfin, il ne faut pas perdre de vue si on évoque la taille des données, qu'il faut y intégrer la taille du code nécessaire à jouer la musique. Le player AYT n'a pas besoin de buffers de décompression alignés en mémoire, ne nécessite pas la présence d'un code d'initialisation pour pouvoir reboucler sans problème et occupe lui même bien moins de place que les autres players.

Mais évoquer la seule taille des données du fichier AYT sans évoquer ses nombreux autres atouts ne serait pas très juste....

Quand choisir AYT plutôt qu’un format plus compressé ?

De nombreux critères peuvent justifier le choix d’un format moins compressé, mais plus performant comme AYT.

Certains critères sont même impossibles à obtenir actuellement  avec des formats fortement compressés :

✔ Taille du fichier compacté hors exécution

Une fois compacté par un packer externe, un fichier AYT est souvent plus petit que d'autre formats déjà compressés. En effet, les algorithmes de compression de ces autres formats ne sont pas les plus performants car ils sont contraints de permettre une décompression rapide et à la volée. Aussi la recompression d'un fichier déjà compressé de cette manière est peu rentable et efficace.

Cela permet au format AYT d'occuper moins de place sur disque et en mémoire avant son exécution, et particulièrement quand le code du décompresseur est plus gros que l’économie réalisée au runtime. On pourrait citer de nombreux exemples, mais pour le programmeur d'une démo limitée à un fichier de 4 kilo-octets, le format AYT est sans doute le meilleur choix.

✔ Player en temps fixe

Les players AYT garantissent une exécution en temps strictement constant, indispensable pour certains usages comme les démos. C'est une notion très appréciables, notamment dans le demomaking qui exige des timings extrêmement précis. De plus, la constance de la CPU reste vraie pour chaque frame, et notamment lors du bouclage ou la fin du morceau lorsque le player passe en "mute". Sur CPC, l'initialisation qui a lieu durant le premier frame est également réalisée en respectant le temps du player.

✔ CPU du player

La CPU du player est le temps que ce dernier prend pour jouer la musique. Sur CPC on l'exprime en général en NOPs (ou µsecondes) et sur d'autres plateformes, elle est exprimée en TS (Timing State ou Cycle d'horloge du processeur). Elle dépend de la plateforme utilisée car l'accès au circuit sonore peut être plus long sur certaines plateformes.
Sur CPC, le player AYT « standard » est actuellement le player AY le plus rapide existant, et le player « + » (optimisé CPC+) est deux fois plus rapide que le player CPC.

✔ CPU d’initialisation

Il s'agit du temps utilisé par le player pour initialiser les registres qu'il n'utilisera pas. C'est une opération nécessaire pour garantir toute fausse note liée à un registre non initialisé. Elle est très faible pour AYT et on peut noter que sur CPC, l’initialisation est  intégrée au player de manière transparente, sans qu'il soit nécessaire d'appeler une routine dédiée comme sur tous les autres players.

✔ Gestion du rebouclage

Le format AYT permet de reboucler n’importe où dans le morceau, et toujours en temps fixe. Les formats compressés ne peuvent en général reboucler qu’au début ce qui peut être bloquant ou complexe à contourner.

✔ Mute de fin propre

Le format et le player AYT assurent un mute déterministe à la fin du nombre de lectures prévu. En effet, certains fichiers au format YM original sont souvent mal terminés ou pollués par des séquences redondantes et inutiles, ce qui peut produire des fins et rebouclages irréguliers.

✔ Absence d’altération des données

La création du format AYT ne modifie pas les données musicales, contrairement à certains players ou convertisseurs qui peuvent induire des approximations ou contentions.

✔ Taille maximale et limites d’adressage

Le format et le player AYT n'impose pas de contraintes fortes ; la structuration interne permet de gérer de  gros fichiers. Ce n'est pas le cas de tous les formats hautement compressés et il est nécessaire de s'en assurer.

✔ Impact de l'adresse Player/Musique

Le format est stable et n’est pas dépendant de l’adresse mémoire, contrairement à certains players sensibles aux alignements de pages, notamment lorsque des buffers de décompression sont impliqués.

✔ Accès à la durée CPU via le builder

Le builder sur CPC renvoie la durée CPU consommée par le player. Cela peut avoir un intérêt indéniable pour un code qui est entièrement (ou partiellement) écrit en temps fixe.

✔ Player multiplateforme

Le format est pensé pour être portable, même si le CPC constitue sa cible principale. Il faut noter qu'au sein même des machines CPC Amstrad, la plupart des player prévus sur CPC fonctionneront aussi sur CPC+, sans toutefois bénéficier de ses atouts particulier. Il existe néanmoins une version de player AYT spécifiquement prévue pour CPC+ pour obtenir un player plus compact et bien plus rapide.

✔ Fonctionnement en ROM

Une version ROM du player sur CPC est disponible afin de pouvoir être intégrée efficacement dans toute production qui impliquerait ce support.

✔ Critères pratiques

La facilité d’utilisation d’un compacteur, la disponibilité d’outils web, les convertisseurs multiplateformes, ainsi que la simplicité d’intégration du player sont également des critères majeurs.
L’écosystème AYT a été pensé pour être simple à utiliser, ce qui n'est pas toujours le cas des formats compressés nécessitant des décodeurs complexes.

D'autres critères sont à l'étude, comme par exemple la possibilité de réutiliser le code d'un player pour différents morceaux, ce qui peut s'avérer déterminant dans un jeu qui a besoin de gérer plusieurs musiques et des bruitages.

Il reste également énormément de sujets à creuser dans le domaine des formats musicaux et des players car c'est un immense terrain d'expérimentation. Certains points durant ce projet ont éveillé notre curiosité et quelques idées se révèlent très prometteuses. Mais c'est une autre histoire que je vous conterai plus tard...😄.

En attendant, j'arrête ici ce long billet et j'en profite pour saluer tous les AYTers qui nous ont accompagné et encouragé de près ou de loin durant ce travail passionnant. Un grand merci à Ced, Made et Med, qui ont contribué par leur immense talent à donner un peu de visibilité à ce beau projet.

Et pardon à tous ceux qui ont du se taper "Le petit pont de bois" que nous avions égaré sur un disque de compositions 😜

Longshot / Logon System

Il y a quelques jours, je suis tombé sur une "démo" d'invitation à un meeting de passionnés, qu'on appelle une "invitro" dans le jargon "démoscènique".

Benediction Coding Party 4 Invitro by Praline & Impact

invitation for Amstrad CPC / Amstrad Plus, released in may 2024

pouët.net2024-06-06 17:04:13

L'objectif de ce type de programme, tout comme les fanzines disques, est en général de se diffuser le plus largement possible auprès des passionnés d'une communauté.

Aussi, ce fut une surprise de découvrir que la dite démo ne fonctionnait sur aucun émulateur à part celui que l'auteur développe. 🙄

Ce dernier a en effet utilisé une découverte qu'il a faite sur le circuit FDC 765, le circuit qui permet de gérer les lecteurs de disquette, pour rendre l'invitation inaccessible aux utilisateurs des autres émulateurs que le sien (et même à certains hardwares réels mais je vais le laisser découvrir ça par lui même 🤣).

Ce billet va évoquer rapidement le FDC 765 et vous présenter un cas concret d'adaptation d'une rupture ligne à ligne sur le CRTC 2.

Magic Fanzine ?

Ce n'est pas la première fois que l'auteur de ce programme se tire une balle dans le pied. Il avait par exemple diffusé en novembre 2023 un fanzine disque qui détecte les émulateurs via leur émulation du FDC 765.

Cependant, la méthode de détection utilisée montrait que l'auteur confond le circuit FDC et les LECTEURS que ce circuit pilote.

Pour déterminer si il est face à un émulateur ou une vraie machine, l'auteur a supposé que seul un lecteur émulé donne des délais constants, sans tenir compte des nouveaux lecteurs qui utilisent de la mémoire.

Concrètement, si son test (présent en #80C9 dans le code) identifie que le délai est similaire en poids faible et est inférieur en valeur à #800, il considère le circuit FDC comme étant émulé.

Le programmeur a triché en "fakant" un test CRTC via son test FDC sur un émulateur ciblé avec une valeur précise (en #8034 dans son code pour les plus curieux). Un article évoque le sujet ici.

Sur de vraies machines équipées de lecteurs numériques, un "FDC réel" est donc parfois détecté comme un circuit émulé. Se pourrait il que le FDC soit affecté d'un vieillissement modifiant son comportement ? 🤣

Tant que le fanzine se contentait d'afficher le résultat de son diagnostic, rien de bien grave si l'utilisateur avait encore accès au contenu, mais il semble également que certains "lecteurs modernes" ne soient pas assez "accurate" pour le loader... Et sans méthode alternative au chargement musical, c'est la fin du film.

Il est également étonnant de voir un programme, et à plus forte raison le fanzine d'un spécialiste auto-proclamé du FDC, ne pas savoir gérer le drive B en 2023.

Tout le monde ne dispose pas d'un inverseur de drive hardware. C'est mon cas.

Et le CRTC ?

Lors de sa sortie, j'avais été surpris de constater l'incompatibilité avec un drive secondaire, mais également de constater qu'il plantait sur le CRTC 2. L'auteur a depuis corrigé ce problème dans une nouvelle version (en positionnant R3 avec 8), mais elle ne tourne toujours pas sur drive B.

Le problème rencontré était des plus classiques sur le CRTC 2, puisque c'est historiquement une des premières différences entre CRTCs qui a été détectée sur les CPC, et qui a par exemple conduit Rémi Herbulot a tenter de les différencier dans son jeu "Crafton & Xunk", moyennant un dégât collatéral sur le CRTC 1.

Lorsqu'un écran fullscreen est positionné à gauche, on modifie en général le registre CRTC R2 pour y mettre la valeur 50. Mais il est nécessaire de respecter la règle R2+R3<=R0, sinon cela déclenche une VSYNC Fantôme.

Autrement dit, si la condition n'est pas respectée, l'écran est désynchronisé verticalement et défile de manière ininterrompue :

Or sur un CPC au reset avec une rom standard, la valeur de R3 est de 14. (R0 vaut en général toujours 63). On a donc 50+14=64. 64 étant supérieur à 63, le signal de synchronisation vertical n'est plus envoyé au moniteur par le GATE ARRAY car il ne le reçoit plus du CRTC (qui pourtant "croit" la faire) et l'image part en vrille.

Etant donné que le programmeur ne s'était pas ennuyé à initialiser préalablement les registres du CRTC, il suffisait pour régler le problème, de taper sous Basic les instructions suivantes avant le chargement de l'ancienne version:

OUT &BC00,3:OUT &BD00,6

Si vous souhaitez en savoir davantage sur cette règle, je vous conseille la lecture du chapitre 16.4.3 du Compendium (https://shaker.logonsystem.eu/)

Magic Loader 🍈

Pour revenir à l'invitro, son programmeur a qualifié son loader de "Magic loader".

Attiré par l'odeur de la magie, il a été craqué par "Magic Soft", qui a repris du service pour l'occasion. 🤣

Ce loader utilise une spécificité de l'architecture du FDC au sein du CPC qui ne sait gérer que 2 drives au lieu de 4 car l'une des broches de sélection de drive du FDC 765 (la broche US1) n'est pas "connectée" (Une autre économie de M. Sucre) et cela permet de s'affranchir, sous conditions, d'une instruction de changement de piste.

Contrairement à ce que les recherches sur d'autres circuits peuvent apporter de plus à l'expérience utilisateur, ce genre de "truc" n'améliore pas le chargement de données. Cela ne va ni plus vite, ni n'apporte plus de données, bien au contraire.

Cela reste néanmoins toujours une très bonne chose de chercher à améliorer la qualité d'émulation des différents circuits qui équipent le CPC, y compris le FDC 765. La méthode employée ici est cependant déplorable et à ranger dans l'étal des melons, notamment lorsqu'on lit le contenu assez présomptueux du readme livré avec la démo.

Il aurait été préférable que l'auteur élabore un programme spécifiquement dédié à ses recherches ou documente sa trouvaille, mais il n'en a malheureusement rien fait.

Tous invités ! 🙄

Avec la version "Magic Soft", tous les CPC réels ou les émulateurs disposant de 128K peuvent désormais voir l'invitation. Tous les auteurs d'émulateurs (ou ceux qui n'ont que 64k) peuvent continuer à jouer avec le "Magic Loader" si "complexe" de la version d'origine. 🤣

A mon humble avis, si vous deviez concevoir prochainement un loader, je ne peux que vous conseiller de changer de piste "normalement"... 😂

Lorsque cette démo d'invitation démarre, elle indique qu'elle ne fonctionne pas sur CRTC 2, ici identifié comme MC6845 :

Après visionnage de la démo, rien de bien difficile techniquement puisque c'est une technique dite de rupture ligne à ligne qui est utilisée pour gérer l'animation. Nous allons étudier cela...

Cette technique a longtemps été réputée impossible, jusqu'à ce que le contraire soit démontré fin 2021 dans Amazing Demo V3 et le Compendium CRTC.

Afin de permettre l'adaptation au CRTC 2 dans les meilleures conditions, il était nécessaire de retirer le "Magic loader".

L'auteur a laissé un code sensé permettre de "regénérer" la disquette qui utilise des fichiers dont on ne connait pas le contenu. Il a été impossible d'utiliser le "bnd4_floppyMaker" pour recréer le dsk-magic-loader sans plantage avec la dernière version d'un émulateur pourtant certifié "accurate" :

Bref, place à Magic Soft, une petite intro écrite par Merlin en 1986...

Tant qu'à faire dans le magique, je conseille à l'auteur d'utiliser "Magic Dos" si il lui arrive de manquer de place à cause des secteurs mono-piste de 4 kb du "Magic Loader".

Magic CRTC ⭐

Rupture ligne à ligne.

Je m'en excuse par avance, mais les propos qui vont suivre seront un peu plus techniques, et il vous faut maitriser un minimum le CRTC et le Z80A si vous voulez comprendre mes propos.

La technique dite de rupture ligne à ligne permet de modifier l'adresse de chaque ligne affichée. En allant piocher l'adresse sur 2 octets de la ligne dans une table vectorisée à partir d'une autre table de lignes sur 1 octet, la mise à jour de cette table (ou de son pointeur d'origine) permet de "déplacer" chaque ligne individuellement et facilement sur l'écran.

Afin de réaliser cette opération, il faut (en général) que le CRTC débute un nouveau "frame". Un frame est un ensemble de lignes déterminé par le moment ou le compteur de caractère C4 repasse à 0. Chaque caractère peut contenir plusieurs lignes, dont le numéro est stocké dans C9. La frontière de C4 est R4 et la frontière de C9 est R9.

Autrement dit si R4 vaut 1, C4 passera à 0, puis 1, puis 0, puis 1, ...

Lorsqu'on est en "rupture ligne à ligne", 1 ligne correspond à 1 frame.

"Si on souhaite obtenir des caractères de 1 ligne, est-ce qu'il suffit juste de mettre R4 et R9 à 0 lorsque C9 et C4 sont à 0 ?" se demande un grand chauve à lunettes qui sait désormais tout sur tout. Le petit blond qui ne comprenait jamais rien à rien a bien changé. Il a même perdu ses cheveux en vieillissant.

Il a raison, mais uniquement sur les CRTC 1, 3 (et 4).

Sur les CRTC 0 et 2, la logique de comptage n'est pas aussi simple.

Sur la dernière ligne du "frame", la remise à 0 de C4 est décidée au début de la ligne, et non à la fin de cette dernière. Donc modifier R4 et R9 au cours de la dernière ligne du frame n'empêche pas C4 et C9 de revenir à 0.

Mais ça peut être utile si on souhaite que la prochaine ligne soit également considérée comme une dernière ligne.

Ainsi il faut positionner R4 et R9 avec la valeur 0 sur la ligne qui précède celle ou C4 et C9 devaient passer à 0.

Exemple concret...

Si on prend l'exemple de cette démo, on remarque ci-dessous dans le premier cadre en rouge une boucle d'attente du début de la Vsync, qu'il ne faut pas confondre avec le début du frame.

La Vsync se déclenche lorsque C4 atteint R7. Sur un CPC standard, la valeur de R7 est de 30, ce qui implique que la Vsync est envoyée au moniteur lorsque le CRTC a géré 240 lignes (30 x 8 lignes). On verra plus tard que cette méthode d'attente de la Vsync est un peu archaïque et manque singulièrement de précision.

La mise à jour de R7 avec une valeur haute après l'attente de la Vsync ne sert à rien, puisque l'idée est de passer en rupture ligne à ligne et de laisser C4 reboucler à 0. Il ne risque plus d'atteindre 30 (ou la future valeur qui y sera mise).

Le test CRTC qui est réalisé au début de la démo permet de mettre #B ou #C dans le premier "ld b,#0c" en jaune, afin d'attendre une ligne de moins la fin du frame en cours. Cela permet donc de positionner le code au niveau de cette dernière ligne afin de gérer la particularité de gestion des CRTC 0 et 2.

On remarque accessoirement une initialisation un peu bordélique de SP et de B', qui vont représenter, respectivement, un pointeur sur des paramètres de couleurs et l'adresse I/O du Gate Array et du PAL (#7F) (ici pour mettre à jour les couleurs).

Comme on le voit ci-dessous, R9 et R4 sont positionnés à 0 (premier cadre rouge), afin que les prochains C4 et C9 soient à 0.

En vert, 2 pointeurs sur des tables qui seront lues dans la boucle de 64 µsec qui part du label lca56 et qui reboucle avec la flèche verte. L'accumulateur (ld a,#ef) contient le nombre de lignes en rupture ligne à ligne.

Finalement, c'est pas plus compliqué que ça une démo de 1991...🤣

Le second cadre en rouge montre, dans cet ordre, la sélection du registre R12 du CRTC, la lecture de la ligne à afficher (LD A,(DE)) et le passage à la ligne suivante (INC E) qui boucle sur 256 valeurs. Grâce à cet index de ligne, cela permet de lire un offset 16 bits pointé par HL afin de mettre à jour d'abord R12, puis R13.

Le troisième cadre en rouge montre la lecture de deux valeurs 16 bits qui contiennent des couples "pen"+"couleur" modifiés en fin de ligne.

Et le CRTC 2 ?

Mais pourquoi ça ne marche pas sur CRTC 2, se demande le grand chauve à lunettes, qui a bien mal révisé son Compendium illustré.

Parce que le CRTC 2 a besoin que R9 soit différent de 0 durant la Hsync pour éviter que C4 ne déborde. Si vous souhaitez creuser le sujet en détail, je vous invite à lire le Compendium.

Concrètement, cela implique de pouvoir modifier R9 deux fois sur la ligne, et que R9 soit remis à 0 lorsque la Hsync est terminée, avant la fin de la ligne.

Si vous vous souvenez de ce que j'écrivais sur R2 et R3 plus haut, R3 définit la taille de la Hsync. On la plaçant au minimum requis (à savoir 6), elle se termine plus vite et il reste du temps pouvoir remettre R9 à 0 avant la fin de la ligne.

Lorsque l'écran est en fullscreen horizontal, on a vu que R2 vaut en général 50 pour un bon centrage. Si R3 vaut 6, il faut que R9 soit différent de 0 jusqu'à ce que C0 dépasse 55, lorsque le signal Hsync du CRTC a cessé :

Le schéma ci-dessus représente une ligne vidéo avec ses 64 µSecondes (0 à 63). Lorsque la position C0=50 est atteinte (R2), une Hsync débute et va durer R3 µsecondes (soient 6 dans notre cas). Le programmeur doit se débrouiller pour que R9 soit supérieur à 0 sur la position 55 (ou plus), mais qu'il soit revenu à 0 sur la position 63 au plus tard.

Pour adapter et patcher le code présenté plus haut, il faut donc d'une part récupérer de la CPU pour faire 3 OUT de plus, et d'autre part synchroniser de manière moins cochonne ce code avec le CRTC.

Optimisation

Je ne vais pas disserter sur la méthode employée pour obtenir l'effet, étant donné que le code d'origine semble avoir été vite expédié. 🐷

Voici une solution toute aussi rapide pour récupérer la CPU manquante, que je vais vous détailler :

J'ai "unrollé" le code afin de récupérer le temps de la boucle. Ce qui signifie que le code ci-dessus est recopié autant de fois qu'il y a de lignes dans la ram.

Il existe quelques méthodes pour faire une vraie boucle et dépenser moins de ram, mais ce n'était pas l'objet de la manœuvre, et cela aurait demandé de toucher à l'organisation des données et/ou du code.

En résumé:

• La mise à jour de R12/R13 (offset) est optimisée en utilisant la particularité du OUT (#FF),A (voir chapitre 23.1 du Compendium) qui prend 3 nop et n'impose pas de modifier B.
• La mise à jour des couleurs ne gaspille plus que HL', laissant DE' libre de contenir le pointeur de ligne, pour permettre à DE de servir à autre chose (E=9 pour la sélection de R9, et D=#BE pour recharger l'adresse I/O du CRTC).
• R9 est ainsi affecté avec une valeur non nulle via le registre B (qui contient #BD, ce qui correspond à #1D car R9 à une résolution de 5 bits), et est remis à 0 en fin de ligne (instruction OUT(C),0 = #ED,#71)

Synchronisation

Il était également nécessaire d'éviter les fluctuations engendrées par l'attente cochonne de la Vsync.

Pour illustrer mon propos, je vais reprendre le code d'attente de Vsync de cette démo, mais étalé dans le temps, µseconde par µseconde pour plusieurs images :

Le "in a,(c)" dure 4 µsec et c'est sur la dernière µsec de l'instruction, symbolisée par un x sur fond jaune, qu'il reçoit l'information sur l'état du signal Vsync dans le registre A du Z80A.

Le signal Vsync s'active très exactement toutes les 19968 µsec. Si le code qui a rebouclé sur cette routine d'attente n'est pas un multiple de 8 µsec, le signal Vsync peut s'activer sur n'importe quelle µsec durant la boucle.

Les 3 exemples avec les "x" en orange symbolisent l'activation de Vsync sur différents écrans et montrent que la sortie de boucle peut subir un décalage de plusieurs µsecondes entre 2 images. Ceci peut avoir une incidence sur le moment ou les circuits (CRTC ou GATE ARRAY) vont recevoir des mises à jour.

Afin d'éviter ces fluctuations inhérentes à la boucle, il existe des solutions, comme la programmation en temps fixe, ou utiliser les interruptions, qui sont aussi dépendantes du CRTC. C'est cette seconde méthode que j'ai utilisée.

Petit rappel sur les interruptions...

Sur CPC, une interruption a lieu toutes les 52 lignes (et la première débute 2 lignes après le début de la Vsync sous conditions). Si ce compteur a été dépassé sans que les interruptions soient autorisées, la première instruction EI va déclencher une interruption immédiatement (après l'instruction qui suit le EI).

Il faut donc éviter qu'une interruption soit en attente lorsque le code attend le signal Vsync. Pour cela il faut laisser le Z80A traiter une interruption à chaque fois que le compteur a atteint 52.

En #38, le code original avait placé un EI + RET. Les interruptions sont réautorisées en #38 jusqu'à l'entrée dans la boucle principale. Un zéro placé en #38 élimine le EI pour le remplacer par un NOP. La boucle d'attente de la Vsync va cependant autoriser les interruptions dans la boucle d'attente.

Lorsque la Vsync a lieu, l'instruction HALT va attendre la prochaine interruption, qui va se produire 2 lignes après. Cette instruction HALT génère des NOP de 1µSec en masse avant l'interruption et on est donc ainsi calé à la µseconde près.

Etant donné que deux lignes ont été perdues après la Vsync, il suffit de diminuer la valeur du compteur d'attente de la dernière ligne du frame en modifiant le LD B,#C qui devient LD B,#A (voir ci-dessous).

Il n'y a plus de EI dans la routine d'interruption située en #38, aussi plus aucune interruption ne se produira. Un DI aurait aussi pu faire l'affaire.

Le bon moment pour réarmer les interruptions...

Je vous ai raconté un peu plus haut qu'une interruption se produisait 2 lignes après le début de la Vsync sous "condition".

Une chose à retenir c'est que si les interruptions sont interdites et que le compteur de lignes a dépassé 51 et rebouclé à 0, une interruption est en attente et le premier EI va déclencher une interruption immédiate ne permettant pas de bénéficier du rebouclage du compteur comme déclencheur.

Le second "effet" indésirable, c'est que lorsque cette interruption immédiate se produit, le bit 5 du compteur est mis à 0. Autrement dit, si ce compteur n'a pas encore dépassé 31 lorsque l'interruption a lieu, la mise à 0 du bit 5 n'a pas d'effet. Par contre, si le compteur valait 32 ou plus, il se retrouve amputé de 32 lignes.

Si ce bit vaut encore 0 deux lignes après le début de la Vsync, alors cette dernière n'a pas lieu. Je vous invite à consulter le chapitre 26 du Compendium si vous souhaitez aller plus loin sur les interruptions du CPC.

Après avoir désactivé les interruptions pendant la rupture ligne à ligne (qui fait plus de 52 lignes) et avant de revenir dans la boucle d'attente de la Vsync, il est nécessaire de purger l'interruption en attente avec EI.

Mais pour éviter de mettre le bazar dans le compteur, il faut le faire dans une période ou le compteur de lignes est inférieur à 32.

Autrement dit, toutes les 52 lignes, il y a 32 lignes ou il est possible de poser un EI suivi de 20 lignes ou le EI va modifier le compteur. Sur le schéma ci-dessous, on peut considérer que les zones en vert sont les 32 lignes ou un EI est possible sans affecter le compteur de ligne.

En sortie des boucles de rupture ligne à ligne, un EI est donc placé dans une zone en vert, afin de ne pas saccager le compteur interne du GATE ARRAY.

Conclusion

Adapter un code au CRTC 2 n'est pas plus compliqué que ça. Et pas bien long non plus à faire, car j'ai du taper moins de 30/40 lignes de code pour y parvenir.

C'est encore plus simple si on ne doit pas patcher du code pré-existant avec des bugs, qui blinde littéralement la mémoire de textes directement intégrés comme du bitmap. Si "grouik" est le cri de guerre de l'auteur - qu'il répète à l'envi - on pourra s'accorder qu'il s'agit même de son crédo. 🐷

Cet article a été nettement plus long à écrire que d'adapter cette démo...

Il est possible que le CRTC 2 ait été ignoré dans cette démo car l'émulateur "accurate fdc" ne sait pas encore l'afficher correctement. Et si ce circuit ne mérite pas l'attention de l'auteur, pourquoi prétendre l'émuler et ne pas directement le retirer de la liste des circuits gérés par l'émulateur...

J'espère sincèrement que cet article vous aura appris quelques petites choses, afin de démystifier un peu ce sujet, et que cela pourra vous aider si vous programmez encore sur cette vieillerie qu'est le CPC ou que vous bossez sur un émulateur.

Longshot / Logon System

🇬🇧 English version

Cet article, dans la continuité du précédent, fait l'étude de "Memory Full", un livre qui prétend décrire l'histoire de la demoscene CPC.

Selon son auteur, le groupe Logon System, n'ayant pas réussi à absorber assez de sang frais, a continué à jouir de son injuste notoriété jusqu'à son déclin et sa mort...

Ce dernier billet conclue l'analyse de ce livre, qui a malheureusement totalement échoué à raconter ce qu'à été la création de la demoscène CPC.

DECLIN D'UNE DYNASTIE...

Lente agonie...

Il est maintenant temps d'étudier la narration de l'agonie de Logon System, qui débute pour l'auteur dès janvier 1991, mais dont le processus est accéléré après l'Euromeeting de 1992....Glirps!

Si Fred fait "Bli", Pict fait "Bla" !

La survie d'un groupe serait donc liée à la fréquence de ce qu'elle produit ?

Logon System produisait du contenu autre que des démos, comme le B-Asic ou les nombreux articles dans A100%, mais ça semble ne pas compter.

C'est comme si on dissertait sur la survie d'un groupe actuel qui n'aurait pas sorti une démo tous les ans 😂 . De nos jours il n'est pas rare que des démos s'écrivent sur des périodes de 5 voire même 14 ans selon les dires de certains...

Logon System existe toujours en 2024 et crée encore du contenu pour le CPC.

L'auteur a également enquêté pour savoir pourquoi Overflow a réalisé une démo en 1992 pour le fanzine T.O.W., et se demande si c'est en réaction au "déclin" du groupe...

C'est simple, nous étions à l'époque très souvent sollicités pour réaliser ce type d'intro ou d'article. Pour ma part, je n'avais juste pas le temps matériel de pouvoir y répondre...

L'auteur semble savoir ce qui se passe dans l'esprit d'un "Overflow ado".

On ne sait pas trop si c'est à cause du déclin de Logon que Overflow a fait cette intro, mais la chose semble actée. La fin approche pour le groupe...

Suite à l'Euromeeting 1992, l'auteur extrapole sur ce que le groupe avait (ou non) produit...

Une fois encore donc, l'auteur est en roue libre totale. Assez hypocritement d'ailleurs, puisqu'il va se perdre en conjonctures ensuite sur ce que nous avions pu commencer à développer (nous allons le voir après)...

Le problème des previews

Afin de bien comprendre pourquoi nous n'avons pas montré (ou très peu) de previews durant l'Euromeeting de 1992, il faut revenir sur l'expérience de The Demo.

Cette démo avait été montrée plusieurs fois en 1990, durant l'Euromeeting 1990 et durant l'Amstrad Expo 1990. Cela avait entrainé quelques plagiats médiocres avant la sortie officielle de la démo (et assez "curieusement", cela n'a pas été évoqué dans l'ouvrage).

Encore de nos jours, montrer une preview peut exposer à des plagiats :

Pour éviter ce type d'attitude, je préférais éviter de montrer des previews, surtout dans un meeting où se rencontraient encore plus de monde en 1992. La plupart des autres membres du groupe partageaient ce point de vue, ayant été témoins des conséquences de ces fuites.

Lorsqu'une "preview" d'une partie d'un travail collectif est montrée publiquement par une personne, c'est sans doute une manière rapide de "démontrer sa valeur" ou de "partager son travail" mais cela entraîne néanmoins plusieurs conséquences néfastes.

C'est dommageable pour les autres participants moins avancés dans leur travail et qui subissent une plus grande pression. Cela diminue l'effet de surprise global et cela peut avoir un effet démotivant pour tout le monde.

Overflow savait que certaines de ses créations (SOTB ou la Delta3D) étaient difficilement intégrables dans une démo. Nous en avions longuement discuté.

Et ce d'autant que les menus de sélection étaient déjà pour nous de l'histoire ancienne. Overflow décrirait mieux que moi la genèse de l'intro SOTB (Shadow of the Beast Cpc Old).

C'était au départ dans la perspective de faire un jeu, avant que cela prenne l'orientation d'un menu bien trop consommateur en place disque. L'information suivante est donc un fake :

L'auteur se demande si KDO (dont le pseudo deviendra ULYSSE) était bien un membre de Logon, mais ne s'est même pas préoccupé de savoir de qui étaient les dessins dans SOTB. La "musique", elle, est de Duffy.

Les tâches de gestion annexe...

En page 74 on découvre que nous étions trop accaparé à gérer notre célébrité et que par conséquent, nous ne produisions plus grand chose...

C'était très long et épuisant de signer des autographes.

De plus, Pict était chargé de cultiver les potirons pour nourrir le groupe. Digit construisait une fusée géante en Lego, et Fred Crazy avait même ouvert une brasserie entre deux concerts. 🍻

La fin arrive...

Sans même savoir ce que nous avions dans nos cartons ou ce que nous faisions, l'auteur conte "le déclin de l'institution Logon" :

Tout y est.

Conflit (fake). Nostalgie avec regrets mélancoliques (fake). Départ de Overflow (fake).

Pour le reste, je renvoie l'auteur à ses charts top 5 tellement la dernière phrase est ridicule dans le principe, et méprisante pour beaucoup d'autres en référence à son échelle de référence "méritocratique".

Si ça continue, on va tous être complètement dépassés dans 2 lignes...

Il ne va quand même pas encore m'accuser d'être un vampire tout de même ?

Intégrer Duncan chez Logon System ? Vous n'y pensez pas !! 😂

Vous la sentez arriver, la fin ?

Je vous parie qu'il va juger le groupe à la seule production d'une démo d'importance en 1992.....

Si on reformule donc, cela rassurait certains de croire que nous étions actifs et à niveau, mais l'auteur conclue que ce n'était pas le cas, sans l'ombre d'une preuve.

Qui sont donc ces nombreuses personnes pour qui Logon ne "tenait plus" qu'à un fil à la sortie de l'Euromeeting 1992. 🤣

On notera la présence "marginale" de Slash.

Je sens que je vais finir par n'être plus que l'ombre de moi-même, incapable de coder, dépassé et écrasé par la gestion de ma "célébrité"...

Le "cherry picking" régulier dans les propos "d'Overflow ado" permet souvent à l'auteur de poser ses désirs comme des réalités.

Même si les différentes sollicitations me ralentissaient, ça faisait partie du jeu et de ma conception du partage d'une passion. Travailler en équipe permet d'ailleurs de se répartir les tâches.

Encore faut il ne pas vouloir tout contrôler... Suivez mon regard...

Et ça m'allait vraiment très bien si l'intérêt se focalisait sur Overflow ou d'autres personnes que moi.

Le dernier numéro de Amstrad 100% "commercial" a été édité en octobre 1993 et nous y avons participé jusqu'à la fin, tout en connaissant de nombreux mois à l'avance la date du dernier numéro.

Nous voulions livrer le maximum d'informations aux utilisateurs en nous répartissant la charge.

Pour ma part en aidant The Cranium à délivrer son article pour le CPC GX+ (N°48) ou délivrer la carte totale des derniers registres de l'ASIC (N°47).

En parallèle dans la rubrique Logon, Digit et Pict ont réalisé des articles dont plusieurs avec du code, dont une démo :

Un dernier sursaut ??

J'espère quand même que l'auteur ne va pas spéculer avec n'importe quoi sur ce que nous préparions alors qu'il vient de raconter que je ne codais plus et que nous vaquions tous à des tâches "annexes"...

Et après ça il n'y a pas de ragots dans ce bouquin... 🙄

Je laisse l'auteur à ses spéculations oiseuses sur l'existence de démos ou de preview Logon non diffusées...

X-Rasters, Démo 4....👻..👻...👻.....👻.........👻............Bouuuhhh!!!

Bien avant 1993, en 1990, il y a eu au moins une démo PC et une demo ATARI ST signée Logon System.

Sur Atari et PC, les codeurs étaient des amis d'étude universitaire. Sur Atari, le pseudo de mon ami Marc était "Logan". Original...😄

Je verrais si je peux retrouver les disquettes originales de ces démos et si il est possible de les transférer. Le premier émulateur capable de faire tourner des démos sur Atari est sorti en 1996.

L'auteur ne sait pas ce que nous allions faire, ne sait pas ce que Overflow faisait (ou pas) et spécule allègrement avec l'idée que le groupe n'existait que grâce à ce dernier ! 🤪

Elle a l'air pas mal cette histoire pour les soirées d'hiver...🦇 🦇 🦇

Le vampire qui agonise car il n'a pas eu le temps d'absorber assez de sang frais.

Je m'étonne quand même que l'auteur n'ait pas ressorti les "histoires" de musiques ST, car c'est quand même un potin qu'il affectionne...

"Ébranlé", le vampire attendait la mort en râlant... Rhaaaaaaa....

De nouveaux Logon ?

Nous allons voir que la personnification constante de la scène démo sert un narratif assez conservateur de transmission générationnelle et de succession, que j'avais déjà abordé dans mon précédent billet.

Ainsi, selon l'auteur, une "scène" ou un "groupe" naît, vit, décline, faiblit, agonise, meurt selon des critères à géométrie variable.

La sortie de "productions" dans un délai personnalisé pour chaque groupe semble être un fil directeur, même si on dénote de nombreuses confusions sur les terminologies informatiques pour qualifier les "productions" ("homebrews" pour des remakes de jeu, "logiciels" pour qualifier des utilitaires,...).

Le "leadership" semble aussi être une thématique chère à l'auteur tant il abuse de termes guerriers pour définir les rapports entre les "entités personnifiées" Longshot versus Overflow/Fefesse, Scène allemande versus Scène Française, Hard versus Soft, Chantal Goya versus AC/DC, ....

Les plus "forts" (pointures de l'époque), les "premiers" (ou les plus visibles) dominent et dirigent tels des "leaders". Il y a une confusion générale entre la date de création d'un "programme" et sa réelle disponibilité dans la scène démo qui vérole littéralement ce montage hiérarchique. L'erreur sur les dates d'émergence des différentes scène démo n'arrange pas les choses.

Même si on ignore cette vision assez effrayante du monde, il n'est pas surprenant ici que l'auteur dissocie Logon System (89-91) de Overflow (92).

C'est une manière peu élégante de mettre tout le reste du groupe aux oubliettes de "l'histoire" pour sans doute traiter le cas "Overflow" ultérieurement, alors que ce dernier s'est étiqueté Logon System jusqu'en avril 1993 (pour y revenir quelques années après d'ailleurs).

N'oublions pas que l'auteur considère que The Demo est une démo somme toute banale et peu innovante, et que ses membres ont usurpé la reconnaissance dont ils ont fait l'objet, tout affairés qu'ils étaient à gérer leur célébrité, chouchoutés par le magazine Amstrad 100%.

Logon System n'a jamais cessé d'exister, et probablement d'inspirer du monde au-delà des années 2000. J'ai parfois rencontré durant ma carrière professionnelle des personnes qui évoquaient Logon au cours de discussions devant la machine à café sur la micro informatique des années 80-90.

Ce n'est pas parce que l'auteur n'a pas les informations sur les activités du groupe après 1993 que ça lui permet de l'enterrer à cette époque.

Le groupe a d'ailleurs, semble t il, continué à inspirer du monde, déjà en 1994 :

Dès 1993, je me suis intéressé aux émulateurs et au transfert du patrimoine numérique sur PC afin d'éviter que tout ne se perde. J'avais conscience de la rapidité exponentielle des évolutions technologiques.

J'ai notamment échangé avec les premiers aventuriers de l'émulation CPC, comme Marco Vieth (auteur de l'émulateur CPCemu) en tentant de l'aider de mon mieux dans cette démarche.

Ayant interviewé Antoine sur son portail il n'aura pas échappé à l'auteur que ce dernier indique que je l'ai contacté en 1999 lorsqu'il a rendu public son émulateur Yage. Et ce n'est qu'un exemple parmi de nombreux autres...

Si aujourd'hui l'auteur peut se permettre de créer des démos et d'en parler, c'est bien parce que la scène a été créée, que l'information a été vulgarisée et que le patrimoine a été transféré !

Contre feu...

Tout au long de ma série de billets, certains ont pu s'émouvoir que j'évoque le dénigrement dont j'ai été la cible durant des années et que j'ai déjà évoqué en préambule de mes articles.

Certains excusent les "erreurs" en indiquant que l'auteur n'avait jamais prétendu détenir la "vérité". En fait il a indiqué en page 5 que "Dans tout travail de ce type, les biais sont inévitables et ne peuvent qu'être signalés en amont, puis minimisés dans la mesure du possible."

Entre quelques erreurs techniques compréhensibles et un récit fictionnel à charge bourré d'erreurs à cause du boycott des sources fiables, il y a un fossé qui a été allègrement franchi.

On peut malheureusement également constater un manque de discernement et une critique à deux vitesses de la part de certaines personnes...

Je tiens à préciser que je me suis attaché à évoquer principalement des éléments factuels et irréfutables.

De manière générale j'ai cité l'intégralité des phrases, la page et dans certains cas la date, et ces citations sont contextualisées.

Je pense avoir l'honnêteté intellectuelle de ne pas dénaturer le sens des citations, à la différence de mes détracteurs.

Ces derniers utilisent d'ailleurs à l'envi un sophisme dit de "généralisation abusive", qui consiste à utiliser un exemple de "démonstration bidonné" pour en faire une généralité sur tous les articles de mon blog.

Cette stratégie démagogique a été utilisée sur quelques réseaux sociaux pour dissuader les personnes de me lire. Pourtant, chacun reste libre de se faire son propre avis.

Mes détracteurs, à court d'arguments, utilisent régulièrement, et depuis des années, une stratégie assez révélatrice qui se vérifie facilement, et qui se résume par :

• "C'était de l'humour et tu n'en as pas"
• "Tu prends la mouche à chaque fois (pour pas grand chose)".

L'auteur et ses comparses ont volontairement ignoré des années que je souhaitais que ce harcèlement cesse. Pourtant, ils savaient que j'allais "prendre la mouche" puisque selon eux, je n'ai pas d'humour. 🙄 Ou du moins, ils pensent en avoir...

La méthode a aussi consisté à étaler tout ça par une accumulation de petites touches ici et là, confinant à un acharnement caractérisé.

On peut également noter l'usage "bien pratique" par quelques personnes de différents pseudos sur certains réseaux sociaux, et la propension à se faire passer pour d'autres personnes en laissant des commentaires qu'ils pensent "amusants".

Ce type de méthode est souvent utilisé par les manipulateurs que sont les pervers narcissiques, qui ont l'art de dénigrer sous couvert de plaisanterie.

La perversion narcissique est largement documentée de nos jours :

PERVERS NARCISSIQUE : 13 signes pour le reconnaître

Découvrez les nombreux signes qui permettent de déceler la présence d’un pervers narcissique en couple ou au travail !

Rédaction par La Clinique E-Santé

IL DIT QUE JE N’AI PAS D’HUMOUR

Le pervers narcissique manie l’art oratoire avec perfection. Lui qui manipule et instrumentalise, cache derrière son humour bien des masques.

Le Pervers NarcissiquePascal Couderc

En général, ce sont des personnes qui se dissimulent sous le masque de personnes sociables, souvent vues comme des personnes humbles, mais il n’en est rien et ils sont le cauchemar d’une ou plusieurs victimes.

Un pervers narcissique se caractérise par quelques signes distinctifs :

Il a un égo démesuré, adopte une posture de victime (inversion de la charge), dénigre les anciennes relations, est en décalage entre ce qu'il dit et montre publiquement et ce qu'il fait en réalité, a besoin d'attention, manque d'empathie, essaie d'isoler ses victimes, surestime ses capacités, utilise un langage de communication flou et ambigu dans tout ce qu'il dit, met ses victimes en position de faiblesse et est un menteur né.

Pas mal de cases cochées quand même !

Un tome 2 ?

L'auteur évoque un futur second tome...

J'informe ici l'auteur à la date de ce billet (juin 2024) que plusieurs des personnes citées dans le tome 1 ne souhaitent pas figurer dans un tome 2. Étant donné le dénigrement et les propos diffamatoires qui m'ont concernés, j'en fais partie.

L'auteur serait plutôt bien avisé de corriger son tome 1 et, par simple respect des personnes, de contacter celles dont il compte parler dans un tome 2 pour leur demander leur consentement :

On peut aussi légitimement se demander, face à l'objectivité du tome 1, ce que pourrait contenir un tome 2 qui couvrirait une période où l'auteur a lui-même été actif au niveau de la scène démo CPC.

Va-t-il décrire son propre travail avec sa conception toute personnelle de ce qu'est une "bonne démo" (sic). Juge et partie... "C'était une très bonne démo mais mon défaut, c'est d'avoir été trop perfectionniste (et de sentir la lavande)."

Il est déjà prévu une série de questions existentielles qui présagent déjà un mode opératoire assez similaire au tome 1 :

S&KOH a été écrite par Overflow. Cette question ne vous rappelle-t-elle pas le traitement de "The Demo" dans l'ouvrage ? Vous avez donc déjà la réponse si vous m'avez lu.

J'hésite... Il est difficile ce quizz !!

Si certains se demandent pourquoi la scène démo est aujourd'hui divisée et pourquoi plusieurs personnes ne sont vraiment pas les bienvenues dans certains meetings (qui prétendent hypocritement le contraire), je les invite à relire mes billets et imaginer un week-end en petit comité à manger en face de personnes aussi drôles et bien intentionnées... Malaise !

L'un des "cocasses" participants d'un de ces meetings s'est d'ailleurs fait passer pour moi en 2023 (encore...) pour s'inscrire et ainsi ironiser sur ma présence, démontrant ainsi à quel point elle était "inattendue"...

D'autres questions débattues dans le tome 2 ?

Quelques éléments de réponses avec de faux commentaires jugés drôles par certains et posés sur la vitrine Vanity concernant cette production :

Sans vouloir trop "spoiler", un article publié le 5 novembre 2010 sur l'ancien portail Push'N'Pop devrait apporter un début de réponse :

Pour les non anglophones, voici la traduction de ces deux premiers paragraphes...

Dans l'article figure ensuite une critique "technique" (que je n'ai pas reproduite ici) des previews de Overflow, et dont la synthèse est la suivante :

Traduction de cette synthèse empreinte d'un humour désopilant...

L'auteur semble être un vrai spécialiste de l'enfumage et du polissage !

Il a évoqué dans son ouvrage un phénomène de "cancel culture" (sic) sans préciser dans quelle mesure il aurait été empêché de publier quoi que ce soit au cours des dernières années. De l'art d'entretenir le flou...

Étant donné que j'ai été ciblé régulièrement dans le tome 1, je n'attends donc rien de bon d'un tome 2.

Aussi il serait déjà de bon aloi que l'auteur revoie sa copie de fond en comble avec le tome 1.

Épilogue

Ici s'achève cette longue série de billets sur un livre qui a, selon moi, raté son objectif car il a été fait avec de mauvaises intentions, sans concertation et dans le dos des principales personnes concernées et citées.

Le livre est si anarchique que l'auteur ne répond même pas à toutes les questions posées dans son propre préambule.

Un comble lorsqu'on voit le nombre de choses répétées en boucle !

Le livre finit par se résumer à une jungle éparse et impersonnelle de pseudos, de noms de groupes, de noms de démos, souvent comparés inutilement entre eux ou avec des jeux, et gangrenée de potins tout aussi inutiles, et est passé à côté d'une époque.

Je tiens à remercier les lecteurs de m'avoir lu jusqu'au bout, en espérant que ces billets leurs ont apporté un éclairage leur permettant de se faire leur propre avis sur la démarche sous-jacente de cet ouvrage.

Si la lecture peut parfois être difficile, l'analyse des propos n'était pas non plus une partie de plaisir mais il était important que je dispose d'un droit de réponse.

Je reste bien entendu accessible pour toute discussion constructive, aussi bien sûr des aspects techniques qu'historiques.

Je remercie vivement les personnes (qui se reconnaitront) qui m'ont fait des retours constructifs et positifs.

A une prochaine fois...

Longshot / Logon System

🇬🇧 English version

TL;DR

Cet article, dans la continuité du précédent, fait l'étude de "Memory Full", un livre qui prétend décrire l'histoire de la demoscene CPC.

L'auteur insinue dans l'ouvrage que Logon System était un groupe d'imposteurs profitant d'une reconnaissance injustement acquise. Il imagine et décrit les stratégies mises en oeuvre pour atteindre cet objectif.

Nous verrons également comment l'ouvrage dérive également sur les transmissions de techniques, inventant d'absurdes passerelles générationnelles...

Jaloux des chouchous ?

Selon l'auteur, la notoriété du groupe Logon System tient à la promotion de ses démos dans le magazine Amstrad 100%, puis à la collaboration du groupe avec le journal en tant que pigistes.

Il a ainsi fait le lien entre le groupe et le journal par l'entremise des différentes Amstrad Expo.

Amstrad Expo 1989

C'est une déformation de mes propos et donc un fake.

Mes propos exacts étaient les suivants : "Of course, I was in all the "AMSTRAD EXPOs". 1989 : First time. I was very impressed... and proud too, (REVOLOG was running on the A100% stand).".

Le CPC dont l'écran était orienté vers le public sur le stand de A100% voyait défiler toutes sortes de logiciels, sous le contrôle du staff de la rédaction, que je ne connaissais pas à l'époque.

C'est d'ailleurs sur ce CPC que j'ai découvert la démo "Phenomena" de Naminu, qui sera intégrée quelques jours après comme une partie de "Amazing Demo".

Ma démo ne tournait donc pas "en boucle".

Vu la teneur des propos, mon petit doigt me dit que Logon System va bientôt se retrouver qualifié de "Chouchou"...

Je suis arrivé à Paris en février 1990 et non en novembre 1990.

Cette dernière date coïncide avec la présentation de The Demo à l'Amstrad Expo 90, car elle était pratiquement achevée. Le "staff de la revue" ne piaffait pas d'impatience et ne m'a pas proposé d'écrire d'articles lors de l'Amstrad expo 89! (qui, en passant, a eu lieu le 9 octobre 1989 et non mi-89)

Amstrad Expo 1990

C'est donc à partir de The Demo pratiquement terminée que le "staff" de A100% m'a proposé d'écrire des articles, notamment car j'avais déjà eu des expériences de ce type dans d'autres magazines (Microworld, MicroPlus, et j'en oublie).

La rubrique dans le magazine A100% n'était pas "axée démo", mais principalement "technique" (High Tech indiqué sur la page). Et c'est une grosse nuance par rapport au schéma directeur du roman.

Une technique permet de faire un jeu ou une démo, qui est le domaine d'application. Un programmeur de jeu est un demomaker qui s'ignore uniquement dans les contes de fées...

La phrase partait pourtant bien... 😬

Je vous le dis, cher lecteur, tout ça va finir en ignoble "chouchoutage" !

En y regardant de plus près sur la photo ci-dessous, on peut se dire que cet écran n'était pas si géant que ça, même pour l'époque... 🙄

Et c'est odieux, mais Amstrad 100% n'avait même pas financé les tee shirts personnalisés !

J'en étais sûr :

Ainsi, après avoir dévoré comme un glouton toutes les forces vives des demomakers pour "ne laisser aucune chance aux autres", Logon System a également noyauté la presse !

Bref, pour cette seule citation : fake, fiel, fake et encore fake.

15 pages par numéro ? 🤣 (Pict nous aurait caché quelque chose ??)

L'auteur nous a donc finalement percé à jour :

En effet, notre projet secret était de renommer le journal, qui se serait alors appelé "Logon 100%" pour occuper toutes les pages et faire de Robby notre roi.

Nous avions prévu de remplacer le nom de la rubrique technique :

Lors de l'Euromeeting 1, c'est le staff qui a fait le trajet avec nous, pas l'inverse.

Robby et Poum ont fait ce trajet de leur propre chef, car le voyage n'était pas financé par la rédaction.

Voici l'injuste publicité "pleine page" évoquée par l'auteur. Il faut ici rappeler que Amstrad 100% mettait en avant les autres créations, que ce soient des fanzines, dessins ou autres démos.

D'autres chouchous ??

Et après ça, il y a quelques personnes qui ne trouvent pas l'ouvrage péjoratif! 😂

Fabien aurait très bien pu écrire dans Amstrad 100% si il en avait manifesté l'envie car le journal n'était pas aussi "hermétique" aux nouveaux venus que l'auteur semble le laisser croire.

Qualifier Fefesse, Stéphane Saint-Martin ou les Logon de "stars" au sein des rédactions est assez péjoratif, dans un ouvrage qui affirme en introduction (page 6): "Je n'ai pas voulu écrire une histoire des héros de la
scène CPC" (...) "Au-delà des prouesses techniques, c'est aussi du phénomène social que j'ai cherché à rendre compte.."

C'est assez réducteur pour tous les autres pigistes qui participaient à la vie de ces magazines et ont contribué à créer la scène démo, tout en considérant finalement que seul le "niveau technique" comptait pour ces journaux.

C'est aussi méconnaitre que c'étaient surtout (et principalement) les jeux qui permettaient au journal de vivre.

Les "Overscan Bits" (tm)

"Overscan bits" est le petit nom que j'ai donné aux "bits" qui permettent d'afficher une image fullscreen sur CPC.

En quoi cette précision oiseuse est elle amusante et pertinente dans ce livre ?

Retour d'ascenseur 🛗 : Il est amusant de noter que si Hicks a bien su coder certaines ruptures ou changement de mode en cours de ligne, il n'a pas encore compris exactement comment cela fonctionne réellement ! La réponse à ses questions, qui n'empêchera pas ses démos de fonctionner (surtout sur CRTC 1) sera apportée dans le Compendium fin 2021.

Je l'ai déjà indiqué dans un billet précédent, mais il m'arrive de donner un nom aux choses qui n'en ont pas encore vraiment ou pour les raccourcir. Ce fut le cas pour le terme "rupture" aussi connu comme "offset splitscreen" chez les anglosaxons, et qui a été adopté par la scène démo CPC, y compris pour ses différentes déclinaisons comme la RFD (Rupture for Dummies).

Concernant les "fullscreen", j'ai nommé "Overscan bits" les bits 10 et 11 du registre R12 du CRTC pour en vulgariser l'usage lorsque j'ai expliqué la technique dans Amstrad 100% N°38, paru en juin 1991 :

Madram s'en est ému dans le fanzine Amslive N°2 de janvier 1998 lorsqu'il a compris qu'il avait été berné et que ces 2 bits participaient à un débordement affectant les bits de page 16K du compteur d'adresse.

Il n'en reste pas moins que ça reste plus court de dire "Overscan bits" plutôt que "MA10 et MA11 du registre 12 du CRTC".

Je n'ai évidemment rien contre le fait de les appeler "Madram Bits" mais ça pourrait prêter à confusion, d'autant que ce dernier a créé en avril 2023 une démo 4k sympathique appelée "Emotion trouble"...😅

emotion trouble by ramdam brouhaha

4k for Amstrad CPC, 6th at Revision 2023

pouët.net2023-04-13 04:39:08

Revolog : Un trop fameux scrolling!

L'usage de l'adjectif "rudimentaire" pour un "trop fameux scrolling" en dit long sur les intentions de l'auteur :

Si on reformule, ce scrolling rudimentaire ne méritait pas un tel accueil du public, puisque le jeu "Mission Genocide" (que 100% des utilisateurs possédaient) faisait déjà les choses "en mieux" et depuis longtemps...🙄

A l'époque, je ne connaissais pas encore la solution "R5" du jeu Mission Genocide, et j'avais donc utilisé une autre technique pour tenter de ralentir mon scrolling vertical. Même si ce scrolling n'est pas "à la ligne" dans la démo Revolog, il est fullscreen en horizontal (contrairement au jeu) et il n'a techniquement rien de "rudimentaire"

Il est au contraire plus complexe à mettre en oeuvre qu'un scrolling utilisant R5.

Si le sujet technique vous intéresse, vous pouvez lire l'encart qui suit :

Prosternez vous, infidèles !

On peut voir ici comment l'auteur distille certaines idées...

On se demande d'où l'auteur sort cette histoire de "culte".

Le côté "intouchable" est sans doute à rapprocher des propos de l'auteur se lamentant qu'il soit tabou de dire du mal de moi...

Je me suis tout de même retrouvé caricaturé à poil dans la chapelle sixtine...

Je ne vais pas commenter davantage, mais on notera la formule passive avec un sous entendu péjoratif.

Je suis intrigué par ce status, aussi je passe ici un appel à témoin pour savoir qui a pu instaurer ce culte dans cette olympe institutionnelle ?

Une scène démo CPC phagocytée...

L'auteur explique à ses lecteurs comment Logon System a géré sa renommée en étouffant les autres groupes par l'absorption des forces vives...🥵

Ci-dessous une photo de moi en train de recruter Overflow en 1920...

Il avait perdu 6 litres de sang frais (et pur) ce jour là...

Une autre photo de l'équipe Logon en 1991, après une petite phase de recrutement militaire, à l'assaut des derniers demomakers disponibles (un peu à gauche, on peut reconnaitre Pict malgré sa petite taille) :

Est ce que ça n'aurait pas un rapport avec le "chouchoutage" qui a permis à Logon de devenir "culte et intouchable" tout en "gérant" leur (injuste) "célébrité" ? 🥳

Plus sérieusement. Le groupe n'était ni culte, ni élitiste, ni intouchable et beaucoup plus proche des gens que l'auteur n'essaie de le faire croire.

Ce n'est ni ma façon de fonctionner ni de voir les choses, encore aujourd'hui.

La bisbille ?

Lorsque l'auteur a interviewé Gozeur en mars 2017 sur son portail Memory Full, il a comme à son habitude essayé de trouver une bonne histoire pour son tabloïde avec une question à peine "ciblée"...

Gozeur va intelligemment lui répondre :

Cette réponse n'ayant sans doute pas été jugée assez croustillante, elle servira quand même à encenser la démo KKB First (très bonne démo au demeurant) :

Vous la voyez la manoeuvre...

C'est Gozeur en fin de puberté qui le dit, pas Hicks ! 🙄

Alors même que Gozeur lui avait indiqué de ne pas tenir compte (à juste titre) des propos d'un adolescent, et que les propos de Elmsoft ne sont pas sérieux, l'auteur s'est abaissé à les utiliser pour justifier que KKB First était une assez bonne démo pour être comparée aux deux megademos de Logon System.

Il n'y a pas de petites économies diraient certains...

Les propos de Elmsoft dans Chain Demo sont également sortis de leur contexte puisque ce dernier écrit en préambule "History Scroll... It will narrate you the story of the glamorous rise and the despicable fall of Logon System. This scroll is ment to be funny, it's a joke".

Bref, Gozeur et Elmsoft n'ont pas été consultés et n'avaient pas forcément envie de voir exhumées de petites invectives d'adolescents (à classer dans les "potins") envers Logon, étalées dans un livre, et de surcroit sans que cela soit honnêtement contextualisé.

Dépassés ?

Dans mon billet numéro 2, j'évoquais la manière dont le roman établit des hiérarchies (techniques) entre les individus, et qui se reflète à travers différents jugements donnés sur les démos de l'époque.

Ces dernières années, l'auteur a porté un jugement public sur mon niveau technique, considérant que je n'avais jamais dépassé un certain "stade" en 1989.

Il a ainsi dénaturé les propos de Overflow dans l'interview qu'il avait donné dans le fanzine "Quasar Disc 3" (fin 2001) en référence à une technique appelée RVI :

Sur la technique de RVI, en relation avec la HSYNC (supprimée), et alors que Overflow lui a indiqué le problème rencontré, il fake de nouveau ses lecteurs :

L'auteur indique dans une note de bas de page que j'attribue "très honnêtement" le mérite de la technique "RVI" à Overflow.

Difficile de faire mentir un courrier manuscrit disponible publiquement.

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

siko's devblogadmin

Mais il élude perfidement le contenu de cette correspondance (août 1992) (qui explique en détail la technique) et la met en relation avec mes premiers essais "malheureux" de rupture verticale (mars 1990) en y associant une remarque de Overflow ado sur cette technique (janvier 1991).

Plus de 2 ans donc après mes "essais malheureux".

Le problème n'est finalement pas de savoir si j'avais (ou pas) le niveau.

Mais on se demande pourquoi l'auteur raconte que je ne l'avais pas ?

Le contenu de mes échanges, les personnes avec qui j'ai échangé, et ce que ça suppose de mes compétences n'avaient vraiment rien à faire dans ce type d'ouvrage (au même titre que certains propos d'adolescents).

Ce qu'il faut retenir, c'est qu'au même titre que mes articles dans A100% permettaient de diffuser de la connaissance technique, j'avais de nombreux échanges épistolaires dans lesquels je n'ai jamais hésité à partager mes connaissances. D'ailleurs, Steph/Siko (ex-Nephilim) l'avait clairement indiqué à l'auteur du livre dans son interview de septembre 2018 :

Toute personne qui m'a réellement cotoyé peut témoigner que lorsque j'aide des personnes à comprendre, j'essaie toujours d'éviter au maximum de donner des solutions toutes cuites.

L'auteur a hiérarchisé les individus en fonction de leur aptitude à ordonner quelques OUT dans une forme grotesque de transmission générationnelle qu'il ne mesure pas....

A propos de Overflow, il va écrire :

Je n'ai fait que guider Overflow pour qu'il se démerde tout seul.

Il est utile de préciser que c'est la même chose entre Overflow et Gozeur.

Overflow a échangé très peu de courrier avec Duncan.

Ce dernier échangeait avec moi... mais je n'y comprenais rien ! 🤣

En août 1992, ce dernier était allé plus loin que nous.

Il avait notamment atteint les "8 blocs sur CRTC 1" en créant des ruptures de 1 nop (mais butait sur le CRTC 0). A l'époque, on pensait encore qu'il fallait "boucler" sur C9 pour y parvenir.

Duncan avait également parfaitement compris le principe de positionnement Hsync pour les changements de mode graphique en cours de ligne.

C'est une chose qui échappait encore à l'auteur en 2018 (voir ce billet pour plus d'informations). Pour quelqu'un qui prétend m'avoir cotoyé, "soit je n'avais pas été entendu, soit il n'y avait rien compris..." 🤣

L'auteur a une idée toute personnelle de la transmission de connaissances...

Cette histoire de "succession" (et non de "tradition") est absurde.

Disposer de datasheets sur le CRTC ne m'aurait pas "avantagé" (demandez donc à ceux qui en ont déjà lu un). En réalité, il n'y avait pas de datasheets chez Ubi Soft comme l'auteur l'a "affirmé" dans une de ses démos ou il a usurpé mon identité pour se faire passer pour moi....

Le bouquin que j'avais acheté était "Clefs pour Amstrad - Système de base" que j'ai corrigé au fur et à mesure de mes recherches. J'ai envoyé un nombre incalculable de photocopies de certaines pages corrigées à mes contacts.

NWC, comme Overflow au début, trouvait ses valeurs empiriquement en testant des tonnes de combinaisons avec des compteurs, sans vraiment avoir bien compris comment ça fonctionnait.

Mon approche a été différente dans la mesure ou j'étais déjà diplômé en informatique et je n'ai donc pas fait les choses au pif avec ce genre de compteurs. Sinon je n'aurais pas pu programmer une ligne à ligne 3 mois après.

Pour revenir à la trame du roman, le drame se profile lorsque la génération perdue débarque sur une planète CPC vide et hantée par les fantômes...

Ressortez les silex !

Plus de connaissances après 1994 suite à rupture de transmission ?? 😂

Ouf!! Finalement non, puisque "Muni de ce document, tout codeur pouvait obtenir des résultats probants via le CRTC" (page 115) 😓

Nous venons de voir quelques uns des messages que l'auteur voulait faire transpirer de son ouvrage à propos de Logon System.

A ce stade, ça dégouline franchement...

L'auteur ayant compartimenté les choses, il faut bien que Logon disparaisse...

Nous verrons donc la prochaine fois comment il enterre le groupe...

Longshot / Logon System

🇬🇧 English version

Cet article, dans la continuité du précédent, fait l'étude de "Memory Full", un livre qui prétend décrire l'histoire de la demoscene CPC.

L'auteur a abordé le phénomène des intros crack de jeux, qui a été pour beaucoup de plateformes le point de départ des scènes démos.

Nous allons voir que ce sujet aurait mérité une investigation un peu plus sérieuse.

Archéologie numérique

Patrimoine : Jeux et démos

Si en 2023, tout monde peut voir fonctionner des programmes écrits au début des années 80 jusqu'à la démocratisation de PC assez puissants au début des années 90, c'est qu'un travail énorme de sauvegarde du patrimoine a eu lieu.

C'est principalement grâce à l'émulation que le transfert du patrimoine "rétro" a débuté dans les années 90. Afin de nourrir les premiers émulateurs, des formats numériques ont été définis pour permettre le stockage des données présentes sur les anciens supports d'information.

On peut saluer ici le travail remarquable de quelques passionnés (Bruno Kukulcan, Denis Dlfrsilver, Maxit, Amaury BdcIron, Zisquier) et qui ont "dumpé" ces dernières années des trésors de la logithèque CPC.

Le "dump" est un processus qui consiste à réaliser une image fidèle sur un support moderne à partir des anciens supports des années 80/90, comme les cassettes audio, les disquettes et les cartouches.

De nouveaux types de fichiers ont été créés comme les ".dsk" pour les disquettes, ".tap" pour les cassettes audio, ".rom" pour les roms qui équipaient les machines ou les jeux en cartouches. Au fur et à mesure, ces formats se sont affinés pour permettre de mieux prendre en compte la réalité de ces supports, notamment lorsque les protections ont elle-mêmes été considérées comme un élément indissociable de ce patrimoine.

Même si c'est de plus en plus difficile, il est encore possible de récupérer des originaux de jeux rares oubliés dans des greniers et encore lisibles malgré les années. Ce travail est long et fastidieux, car il est aussi accompagné d'un travail de conservation de tout ce qui peut se rapporter au logiciel (jaquettes, photos des supports, solutions, publicités, commentaires, interview d'auteurs, anecdotes, typages...).

On peut citer CPC-Power comme étant actuellement le portail de référence avec la base de données CPC la plus complète à ce jour.

CPC-POWER, sauvegarde du patrimoine de l’Amstrad CPC

CPC-POWER/CPCSOFTS est une base de donnees conservant le patrimoine de notre jeunesse pour les machines suivantes : ordinateur amstrad cpc 464, cpc 472, cpc 664, cpc 6128, cpc 464+, cpc 6128+ ainsi que la console gx 4000.

Je profite également de l'occasion pour souligner le travail remarquable réalisé par Frédéric BELLEC avec son portail "Amstrad Cpc Memoire Ecrite", qui est une véritable mine d'informations sur les documents relatifs au CPC:

AMSTRAD CPC MEMOIRE ECRITE - Préservation du patrimoine littéraire du micro-ordinateur AMSTRAD CPC

Amstrad CPC Mémoire Écrite

Fredisland

Beaucoup de programmes commercialisés à l'époque ont malheureusement été perdus, notamment ceux qui ont eu peu de succès.

J'en ai fait l'expérience avec le jeu que j'avais développé en 1985 pour Cobra Soft. J'ai mis des années à récupérer, auprès de certains collectionneurs, des enregistrements audio du jeu sur les différentes plateformes, et notamment sur les ZX SPECTRUM et THOMSON. Il a ensuite été nécessaire de traiter ces données brutes avec les passionnés de ces plateformes pour obtenir une conversion numérique de ces données, puis faire quelques corrections.

Je m'étais déjà livré à cet exercice difficile avec mes différents programmes personnels sur cassette pour Oric, mais je n'ai malheureusement pas pu tout sauver, la chaleur ayant eu raison de mes premiers programmes. Mon père a eu la brillante idée de mettre mon ancienne armoire dans un local surchauffé en été...😱

Les démos font partie d'un phénomène culturel dissocié du monde du jeu vidéo. La sauvegarde de ce patrimoine a été plus sensible car tout n'a pas circulé de la même manière. Une grande partie des acteurs qui composaient les scènes démo sont purement et simplement passés à autre chose, remisant leur machine au grenier dans le meilleur des cas.

En ce qui concerne les "intros" placés devant les jeux crackés, le niveau de perte a été colossal car sur CPC il n'existait pas réellement d'unité de "scène de crack" comme ce fut le cas pour la "scène démo" dont j'ai dressé l'historique (réel) dans mes billets précédents.

J'ai fait partie de ces premiers à transférer une très grosse partie de mes collections de disquettes vers 1994/1995 (environ 400 disquettes) et en rendre public une partie (les disquettes qui ne contenaient pas de previews ou de courriers "writter") afin que certaines choses ne soient pas irrémédiablement perdues.

J'ai disposé assez tôt d'un lecteur de disquettes 5''1/4 "fait maison" sur mon CPC, ce qui m'a permis de réaliser un archivage que peu de personnes pouvaient se permettre à l'époque.

Si on devait prioriser les chose en terme de sauvegarde de ce patrimoine, on peut sans aucun doute considérer que les jeux et les démos les mieux distribuées ont bien survécu, contrairement aux "intros cracks".

Patrimoine : Intro Crack

Les réseaux de cracks étaient plutôt assez régionaux, dépassant assez rarement les frontières des départements pour de multiples raisons. Ces réseaux étaient en premier lieu constitués d'adolescents scolarisés et il faut se rappeler qu'au début des années 80, envoyer des cassettes ou disquettes par la poste était non seulement cher, mais hasardeux.

Tout le monde n'a pas disposé immédiatement de lecteurs de disquettes, et lorsque ce fut le cas chez Amstrad, le choix du format 3" a eu des conséquences catastrophiques, car les disquettes n'étaient pas seulement chères (60-70FF de l'époque), mais elles étaient aussi introuvables. Le format 3" avait d'ailleurs déjà pratiquement perdu le combat face au format 3"1/2 adopté par les IBM PC. Hebdogiciel s'était fait l'écho de cette pénurie :

Ce qu'il faut bien comprendre, c'est qu'à l'exception des crackers qui ont "continué" sur la voie du "demomaking" ou qui avaient un peu plus de visibilité en étant actifs au niveau de la région parisienne, énormément d'intros de crack ont littéralement disparu.

Dans son roman, l'auteur me cite parmi les crackers car "on vit" circuler mon nom ou mes intros :

Sans s'attacher aux personnes qui crackaient des jeux, il est assez naïf de considérer qu'en recherche de "notoriété", ils avaient des plans de "diffusion de leurs oeuvres".

Cependant, sans les transferts que j'ai réalisés de mes programmes, il n'y aurait aucune "trace" de mon activité de cracker dans les "archives" numériques. Mes intros n'auraient simplement pas "existé". Et il faut bien avoir conscience que peu de personnes ont pensé ou eu les moyens de sauvegarder leurs "créations".

Une vision hors sol...

L'auteur, à défaut de disposer de suffisamment de ressources numériques, et sans avoir contacté nombre d'acteurs de l'époque, en arrive à émettre une vision du passé hors-sol.

Il considère par exemple qu'il n'y avait (pratiquement) pas d'intro crack entre 1984 et 1986.

Pire encore, au détour d'une phrase alambiquée, il croit que les premiers crackers sont "apparus" comme par enchantement 4 ans après le lancement du CPC, donc en 1988:

Il pense par ailleurs qu'il est impossible de connaître les débuts avec précision...

Si on ne peut pas connaître les "débuts avec précision", à quoi servent ses spéculations, surtout lorsqu'elles sont basées sur des archives numériques trompeuses et que certains acteurs de l'époque ont été volontairement mis de côté.

Si des crackers existaient avant 1988, c'est eux qui étaient les "premiers", pour reprendre la thématique chère à l'auteur.

Le phénomène des protections de jeux

A défaut d'avoir consulté des "crackers" et "éditeurs de jeux" de l'époque ou retrouvé assez d'archives, l'auteur pense qu'il est impossible de dater quoi que ce soit et décrète sur cette base que les "premiers crackers" ont fait leur apparition de manière "importante" environ 4 ans après le lancement du CPC, et que les éditeurs ont commencé à protéger les jeux à cette époque.

Il complète le tableau en indiquant que les premières "intros" datent de 1987/1988 🤣.

Il faut ici rappeler que la micro-informatique familiale n'a pas débuté avec le CPC et les éditeurs n'ont pas "attendu" avant de protéger leurs jeux, vu ce qu'il s'était passé sur Apple 2 (mais c'est une autre histoire).

Les premiers CPC 464 sont arrivés en France en septembre 1984, et déjà les éditeurs, comme OCEAN, protégeaient leurs jeux et prenaient la chose très au sérieux, comme on peut le découvrir dans ce reportage d'époque :

Il ne faut jamais douter de la détermination d'un adolescent qui souhaite jouer au lieu de faire ses devoirs. 😂

Les jeux ont été crackés en masse dès le premier jour et il n'a pas fallu attendre 2 ans pour les voir apparaître, ni même 4 ans avant de voir apparaître des intros ! Que l'auteur du roman raconte qu'il n'en ait pas de trace ne fait pas force d'histoire, et c'est surtout absolument faux pour une personne qui a réellement vécu cette période.

Cela s'explique simplement.

De nombreux acheteurs du CPC, comme moi, possédaient déjà une machine de première génération (Oric, C64, Zx Spectrum, TI99-4a, Dragon 32 ...). J'ai créé Magic Soft sur Oric en 1983, avant même d'entendre parler du CPC. Mon acolyte Nicolas, qui m'a appris le Z80A, possédait un Dragon 32. Comme bien d'autres, je n'ai pas attendu le CPC pour mettre une intro devant un jeu cracké.

Tous ces utilisateurs avaient déjà pris "goût" aux jeux gratuits et affronté des protections devenues très coriaces sur leur plateforme. Et sur Oric, par exemple, il y a eu des trucs assez costauds. Autant dire qu'ils n'ont pas été arrêtés bien longtemps par la "protection" de "Roland in the caves" ou de "Fruity Franck" 🍓

L'auteur n'a pu se baser que sur le patrimoine que moi et plusieurs personnes avons réussi à préserver à la fin des années 90, et surtout ce qui a été rendu public. Il aurait été pertinent de poser la question à des crackers ayant commencé avant 1987/1988 pour le savoir...

Classement de crackers...

L'auteur se permet de souligner la médiocrité des rares cracks de 1985-1986 en racontant que les jeux n'étaient pas au format fichier ou disposant de "cheat mode" intégré. Sachant que la majorité de ce patrimoine a disparu, ces jugements de valeur sont des opinions sans objet.

Sur les disquettes que j'ai rendu publiques, et notamment mes cracks en 1986, les jeux étaient bien mis au format fichier lorsque ça présentait un intérêt au niveau du stockage, puisque les supports valaient le prix d'un rein.

Mon prof de philo à l'époque s'était spécialisé dans la création de "cheat mode" tout ce qu'il y a de plus propre.

Certains jeux sur cassette ont d'ailleurs été transférés sur disque lorsque seule la version cassette était disponible ou que cela présentait un intérêt au regard de la protection.

J'ai par exemple en mémoire le cas du jeu "The Way of the Tiger" en 1986. Avec Nicolas, nous avions souffert car le loader "cassette" du jeu rechargeait le code du "loader" sur lui-même et il a donc fallu remplacer toutes les routines cassettes par des routines disques auto-écrasables.

Un apprentissage du Z80A à la dure ! 😓

L'auteur l'a zappé dans son roman, mais mes deux premières intros datent de 1986. Ces "intros" n'ont certes pas de "scrolling" ou de "musique" mais l'une d'elle faisait appel au CRTC (flipping de page et redimensionnement dynamique). Lorsqu'on devait caser 3 jeux par face, il était nécessaire de limiter la place accordée à l'intro pour éviter qu'elle soit supprimée.

Les premiers réseaux !

Zéro internet ! Zéro portable !

Cela va parler aux plus anciens, mais en France dans les années 80, le téléphone coûtait un bras dès qu'on appelait loin.

Au delà de 50 kilomètres, le tarif dépendait d'une des 465 circonscriptions et d'une unité de temps variable, souvent inférieure à la minute.

Les parents sont alors rapidement devenu très vigilants dès que le téléphone était utilisé par leur progéniture, et à plus forte raison ensuite avec l'arrivée du minitel dès 1980 car le système de facturation Télétel était particulièrement juteux pour France Telecom.

Il était assez difficile d'échanger avec des personnes qui habitaient à l'autre bout de la France (et on ne parle même pas des autres pays, à une époque ou l'euro n'existait pas et ou l'anglais n'était pas vulgarisé comme aujourd'hui).

Pour initier des contacts, il fallait passer par des annonces comportant un numéro de téléphone ou se limiter à quelques rarissimes clubs informatiques.

Micro Système était un de ces premiers mensuels de vulgarisation informatique qui a permis à des utilisateurs d'une même plateforme de rentrer en contact. Si vous avez tenté de lire le disque ci-dessous sur une platine vinyle en mai 1983....vous êtes vieux ! 😅

C'est grâce à ces annonces que j'ai pu échanger avec des programmeurs de talent comme le créateur du jeu "Le manoir du docteur Génius" sur Oric, un des premiers jeux d'aventure "graphique" français qui a servi de tremplin à la société Loriciels.

Ce contact a également créé plus tard le jeu Orphée sur CPC, qui utilisait de la synthèse vocale sur un principe déjà très bien connu des utilisateurs Oric, puisque cette machine dispose du même processeur sonore que le CPC.

La fiabilité des supports et des échanges...

Les échanges postaux des premières cassettes ou disquettes étaient une loterie, car les "copies" ne passaient pas toujours et parfois 1 programme sur 2 était corrompu.

Les cassettes et disquettes souffraient de problèmes divers liés soit au transport, soit à la qualité des supports, ou même encore aux différences d'azimutage des lecteurs entre les machines, puisqu'à part le 464, peu de machines disposaient d'un lecteur intégré. Si le sujet vous intéresse :

Dans le domaine, Thomson avait fait très fort car ils imposaient des lecteurs de cassettes dédiés qui se révélaient assez mauvais. Ils avaient même réussi à créer un drive ne pouvant pas dépasser 80K par disquette.

La diversité des lecteurs de cassette branchés sur les différentes plateformes, comme les 664 ou 6128, n'a donc pas arrangé les choses, et je pense que certains ont du garder un souvenir ému de quelques "Read Error b" ou s'étonner que leur disquette ou cassette en "retour" était devenue inutilisable une fois passée dans le lecteur du correspondant.

Expédier des cassettes et/ou disquettes par la poste coûtait également cher, surtout pour des adolescents sans le sou, et ce même si des "astuces" de truands dite "colle en stick" circulaient pour permettre la réutilisation des timbres.

Tout ceci explique pourquoi les "scènes de crackers" se sont principalement développées localement sans dépasser les limites régionales.

Les motivations...

En général, l'intention première était de pouvoir jouer gratuitement et ne pas se laisser berner par des jaquettes alléchantes masquant un jeu médiocre.

La recherche de notoriété n'était pas du tout le moteur de cette activité pour beaucoup. Comprendre et casser une protection était souvent bien plus intéressant que le logiciel qu'elle protégeait. Et pour mon petit réseau, c'était juste le fait de pouvoir disposer de jeux gratuits et échangeables.

Les "cracks" faisaient également gagner de la place lorsqu'un jeu occupait toute une face de disquette à cause de la protection, et permettait également de faire fonctionner le jeu à partir d'un drive secondaire sans avoir à bidouiller avec son fer à souder dans les entrailles de la machine pour "inverser" les lecteurs via un interrupteur.

Il était également courant que les écrans de présentation soient sacrifiés pour gagner quelques kilo-octets de stockage, surtout avant que ces derniers soient compressés.

Il arrivait aussi que les "intros" soient supprimées. La raison majeure était d'abord économique, à cause des problèmes de taille de support au regard de l'augmentation croissante des jeux produits par les éditeurs et de ce que j'ai expliqué plus haut. Les petites guerres d'égo d'adolescents évoquées par l'auteur sont juste des potins à la noix. Les personnes qui vendaient les jeux ne souhaitaient évidemment pas qu'on puisse savoir d'où venait leur "marchandise".

Il a fallu attendre que les drives 5''1/4 se démocratisent un peu plus pour que les programmes "crackés" cessent d'être "élagués".

C'est pour cette raison sans doute que, bien des années plus tard, j'ai découvert de nombreux écrans de présentation de jeux.

Le réseau en Île de France...

On peut supposer qu'au niveau de la région parisienne, plus densément peuplée avec un réseau plus maillé, certains crackers avaient atteint une plus grande "notoriété", comme ce fut le cas pour X-OR, Celtic Gang, TB Crackers, Exocet et quelques autres, car ils ont bénéficié d'une publicité liée aux "pokes" publiés par Amstrad 100% grâce à leur aide :

Leurs productions se sont alors retrouvées sur un plus grand nombre de disquettes. Je n'avais cependant jamais vu de jeux crackés par ces derniers circuler dans ma région avant de rencontrer Fred Crazy en région parisienne en 1989.

Eux-mêmes d'ailleurs ne connaissaient pas davantage le nom de mon groupe de crackers (Magic Soft), ni les groupes situés dans d'autres régions.

Les scènes de cracks se cantonnaient même parfois à des villes moyennes.

Finalement, la seule chose qui a peut-être dépassé les frontières de ma région fut un programme que j'ai appelé "Anti Multiface" (1987).

Ce programme permettait d'utiliser un programme sauvé avec la cartouche sans que la cartouche soit connectée, et offrait aussi la possibilité de démarrer le jeu à partir du second drive, à une époque ou la cartouche était encensée et plébiscitée dans de très nombreux magazines anglais.

Il est cependant fort probable que ce programme soit arrivé en région parisienne via mes premiers échanges en août 1989 avec Rubi.

Robby, l'ex rédacteur en chef du magazine Amstrad 100%, me l'a montré en 1990, lors de ma première venue dans les locaux du journal sans savoir que j'en étais l'auteur. Il m'a appris qu'il y avait un bug dans certains cas et j'ai donc pu corriger le problème.

Pour l'anecdote, ce programme était initialement destiné à mon ancien professeur de philosophie au lycée qui possédait l'interface et avait son propre réseau spécialisé dans les jeux "budgets".

C'est aussi grâce à sa Multiface 2 que j'avais récupéré la rom de la cartouche et que j'ai pu élaborer la protection que j'ai posée sur la démo "Revolog".

Je ne me rappelle plus la date exacte, mais Richard Fairhurst (CRTC) m'avait sollicité car il cherchait à collecter un maximum de logiciels libres afin d'étoffer sa bibliothèque "Public Domain". C'est sans doute ainsi que ce programme, ainsi que Magic Dos (820k/disquette), MPack (rsx gestion de mémoire) ou même le "B-Asic" se sont propagés en Angleterre.

Le "Public Domain" en Angleterre était très apprécié et plébiscité par plusieurs magazines, comme Amstrad Action ou Cpc Attack :

Ces exemples montrent que sans un appui journalistique à cette époque, il était improbable que des intros de crack puissent circuler bien loin ou que la moindre "notoriété" puisse exister au sein d'un réseau peu dense et très fragmenté.

Et par voie de conséquence, de nombreuses intros sur CPC n'ont pas survécu lorsque les petits réseaux se sont effondrés, et que leur utilisateurs ont remisé leurs machines dans les greniers.

La scène anglaise de démo n'a d'ailleurs jamais vraiment décollé, car la presse a commencé à évoquer les démos en 1992/1993, ce qui était déjà bien tard pour la machine, et comparativement aux scènes allemande ou française.

Il peut sembler logique de chercher un trait d'union entre les intros et les démos au regard de ce qui s'est produit sur toutes les autres scènes.

Mais au regard des erreurs d'appréciation que j'ai évoqué, il est assez réducteur de conclure "qu'on n'invente pas le demomaking deux fois" en racontant que les deux phénomènes ont débuté ensemble.

Sans inventer n'importe quoi à partir d'archives numériques perdues, il faut juste se souvenir que les demomakers ont pour une grande majorité acquis leurs compétences par le déplombage en mode autodidacte et que c'est bien une bonne partie de ces personnes qu'on a retrouvé dans le monde du demomaking lorsque cet univers a lui même été plébiscité par la presse qui avait survécu.

Et ce n'est pas pour rien si en France jusqu'en 1989, beaucoup de groupes avaient un nom contenant encore la lettre "C" (Cracking) dans le nom de leur groupe...

Nous verrons prochainement comment l'auteur essaie de faire croire que Logon System était un groupe d'imposteurs profitant d'une reconnaissance injustement acquise...

Tout un programme !

Longshot / Logon System

🇬🇧 English version

Dans ce billet, je vais évoquer plusieurs erreurs que j'ai vu passer dans le roman "Memory Full", qui prétend relater une histoire de la demoscène CPC.

Je vais évoquer un florilège non exhaustif d'erreurs diverses qui émaillent l'ouvrage et qui auraient pu être évitées...

Dans le meilleur des cas, on peut espérer que l'auteur utilisera les informations contenues dans ces billets pour réécrire une histoire correcte (et exempte de ragots et d'accusations) tout en citant ses sources.

Les graphistes de 5KB

Selon l'auteur, les démos des 5KB ne bénéficieront pas de graphismes des graphistes Jon et de Bittlejuice (pour la 5KB Demo 3) :

Si Jon n'a effectivement réalisé aucun graphisme pour les 5KB, ce n'est pas le cas concernant Bittlejuice. Un écran valant mieux que mille mots :

Les raisons pour lesquelles la démo n'a pas été achevée ne regardent personne. Les amateurs de ragots peuvent lire l'ouvrage qui en contient à foison.

Optimisation de player

Selon l'auteur, Overflow aurait optimisé le player de Music Pro...

C'est inexact.

Overflow fait partie de ces personnes qui ont "contribué indirectement" et "sans le savoir", et donc sans avoir été consulté :

Mais bon, il en a été "remercié également".... 🤣

Un hommage au vitriol...

J'ai déjà écrit sur ce sujet. Il ne s'agit pas du tout d'un hommage.

Voir mon billet ici

On se demande à partir de quelles données s'appuie l'auteur pour prétendre que de nombreux codeurs se "considéraient" incapables de faire mieux en 2007 et si c'était vrai, pour quelle raison ne serait-ce toujours pas le cas de nos jours ?

"Comme on a pu le voir..."

L'auteur s'amuse à ranger les programmeurs dans des cases :

Etrange manie de ranger les individus dans des cases bien ordonnées.

Il est absurde (et réducteur) de classer les individus de cette manière. Rubi et moi étions déjà des professionnels en informatique à l'époque, étant pour ma part déjà diplômé.

J''avais déjà développé des jeux, en autodidacte comme professionnellement, et je m'intéressais donc de près à de nombreux sujets.

Nous n'étions donc pas "spécialisés" sur des circuits précis.

L'auteur fait peut-être cette méprise car il en fait une montagne technique car il n'est pas informaticien.

Cette affirmation devrait bien faire rire Rubi qui, comme on le sait, ne parlait que de FDC dans les Rubidouilles de Amstrad 100% :

Lorsque nous avons compilé The Demo, Rubi avait créé un système d'interface entre le CPC et l'Amiga, relié par un câble.

Le CPC pilotait ainsi l'Amiga comme un système client serveur pour compresser les parties et exécuter Zeus, un compacteur maison Logon.

Le jeu Zap't'Balls !

Son sprite hard

L'auteur évoque une rumeur technique que tout le monde "aurait" gobé....

Il est vrai qu'avec la bonne séquence, le CRTC 4 permet d'accéder à 13 sprites hard et 376 couleurs pour l'encre 7. 🤠

Plus sérieusement, ce genre de bravades dans les textes de la Chain Demo sont passées inaperçues ou simplement considérées comme fantaisistes. Je n'en avais même pas connaissance, alors que j'ai eu plusieurs échanges nourris avec Elmsoft à l'époque.

On se demande donc comment une rumeur serait née de ce texte puisque aucun fanzine ne s'en est jamais fait l'écho.

Qui aurait d'ailleurs pu croire sérieusement une seule seconde qu'un CPC (non "+") en 1992 disposait de sprites hardware, qu'aucun auteur de jeu n'avait jamais découvert avant....🙄

Sa commercialisation...

Toujours en référence au jeu évoqué juste avant, l'auteur évoque la commercialisation du jeu créé par Elmsoft :

C'est inexact.

Le jeu était achevé et en vente durant le meeting.

C'est inexact.

Et c'est ce qui arrive lorsqu'on lit les interviews en diagonale. Je suis bien placé pour le savoir puisque j'ai indiqué comment commander le jeu dans le test que j'ai réalisé dans Amstrad 100% N°45 :

Recrutements massifs chez les demomakers...

L'auteur croit que les groupes s'agrandissaient pour suivre l'exemple de Logon :

Ces affirmations ne reposent sur aucun élément factuel.

Cette mode des "méga groupes" n'était absolument pas spécifique au CPC.

Elle s'explique assez simplement.

Il suffisait de quelques meetings pour que des amitiés se créent avec beaucoup de bonnes intentions sur le moment, et que cela devienne ensuite un joyeux bordel à gérer, avec effondrement garanti ensuite.

Contrairement à ce qui est raconté, Logon System s'est constitué de la même manière, à partir d'une amitié née des premières rencontres autour d'une passion commune et pas sur présentation d'un CV "élitiste". (les "rencontres officieuses entre pointures" évoquées page 66 par l'auteur par exemple...).

C'est avec une période assez longue et stable ensuite que nous avons pu produire une démo dont on pouvait être fier.

A partir d'un certain nombre de personnes sur un projet en cours, il est nécessaire de ralentir les "adhésions" malgré les candidatures afin d'éviter que cela devienne ingérable.

Overflow a finalement sorti sa démo S&KOH de manière isolée en partie à cause de ça. Plus il y a de monde, plus il est difficile de coordonner les choses et de s'adapter aux calendriers et contraintes individuelles.

La démo est une activité non lucrative. Ce n'est pas une "contrainte" et aucun "leader" ne "force" personne d'une "main de fer". Ecrire le contraire est un mensonge.

Les coopérations, comme celles que nous avions eu avec ZebigBoss et Hightower étaient possibles, mais pouvaient vite devenir un problème dans la perspective d'une démo scénarisée si trop de groupes figuraient dans le menu.

Il faut aussi avoir conscience que pour beaucoup, l'expérience des démos était juste un passage, une étape avant d'autres dans la vie. Coopter de nouvelles personnes désireuses de continuer l'aventure sur d'autres projets faisait sans doute "monter" le chiffre public du nombre de membres dans un groupe...

Mais un groupe n'est pas une gare de triage ou on jette les "improductifs".

Aussi, s'attacher au nombre de personnes n'est pas très important car ce qui compte, c'est bien ceux qui ont encore du temps disponible et de la motivation pour d'autres projets communs.

Aussi, je laisse l'auteur à son délire sur le vampirisme des forces vives de la scène ou sur les membres officiels/officieux du groupe...

Le B.A-BA du OneScreen !

Connaissiez vous la convention de la "bonne démo CPC" ?

Il s'agissait peut-être du bureau de contrôle FADAISE (Fédération des Analystes en Démo Amstrad Incluant un Seul Ecran) qui vérifiait que chaque démo avait bien son petit plasma (certifié sans couleurs has been)... 🙄

Longshot "out of order"...

Une fois de plus l'auteur est en roue libre en imaginant mes activités en 1992...

C'est inexact.

L'auteur prend ses désirs pour des réalités.

J'ai continué à écrire des articles dans Amstrad 100% jusqu'en juillet 1993.

Mais cela ne signifie pas pour autant que je ne travaillais pas sur des sujets de démo, et vu que je ne communique pas sur ce sujet, l'auteur a plus ou moins fantasmé.

Une partie du groupe avait fait le déplacement en Allemagne le 16 avril 1993 pour assister au Castle Meeting 1A qui a eu lieu à Ochsenhausen :

Etonnant pour un groupe qui n'avait plus d'activité...

N'oublions pas que l'auteur considère que le groupe passait du temps à gérer sa célébrité (page 74, page 121) et nous devions certainement être là pour ça...🤭

HUMILIATION !

L'auteur est de nouveau en improvisation en évoquant la megademo Voyage 93 (juin 1993) créée par des démomakers Allemands :

Comme on peut le voir sur la photo précédente datée de avril 1993, on sent la vexation derrière les sourires de façade crispés... 🤣

Nous avions profité sur place du visionnage de plusieurs des parties de Voyage, ainsi que du Turndisk parodique qui nous avait fait bien rire.

Je ne me suis jamais moqué des allemands ou de qui que ce soit.

C'est un mensonge de plus dans une liste déjà bien longue.

Il est néanmoins intéressant de voir comment l'auteur gère les territorialités dans son narratif guerrier, puisque la scène démo est, pour lui, faite d'armées, de combats, de conflits, de vainqueurs moqueurs et ironiques, de vaincus vexés et humiliés.

Saine ambiance !

Pattern or not Pattern ?

En matière de musique "Amiga", une chose...

Et son contraire...

Bref, c'est inexact.

Quelques informations que vous ne pouviez pas trouver dans le roman :

Fefesse a créé en avril 1991 la première version de son player TCB TRACKER (4 voies mixées en 8 bits, freq 11.5 Khz) qui peut jouer différents MOD.

Il a créé la seconde version en août 1991 après le meeting en Allemagne.

Y'a la rate, qui s'dilate....

L'auteur évoque la fameuse technique de rupture verticale dont j'évoquais la genèse dans mon billet précédent, et, on croit rêver, donne son avis d'expert sur les "attendus" techniques:

Il est bon de rire parfois.

Rendez vous ici, pour les plus motivés pour saisir toute l'ineptie du propos. 😄

Il n'a bien sûr pas fallu attendre 2006 pour observer la première rupture verticale "propre", et cette déformation de la réalité pour arriver à cette conclusion est finalement assez péjorative envers les pionniers.

Le renouveau du CPC !

Voici le contenu qui symbolise le renouveau sur CPC :

Impressionnant ces deux articles !

Le Z80A et ses SP=SP+2 ne s'est également toujours pas remis de cette démonstration sur les listes chainées :

L'usage de la pile existe depuis des lustres pour gérer des listes chainées, que ce soit sur CPC ou n'importe quel système informatique. Rien de neuf.

Si on peut tirer quelque chose de cette flagornerie :

Sur une liste chainée simple (à sens unique), une structure de donnée(s) contient comme première donnée un pointeur vers la structure suivante.

En Z80A, il suffit pour cela de faire un POP HL / LD SP,HL pour que SP pointe sur l'élément suivant. Et lorsqu'on est sur la structure souhaitée, ce sont les instructions entre le POP HL et le LD SP,HL qui permettent de récupérer les données contenues dans la structure.

Si POP SP existait, ce serait sans doute plus lent que les deux instructions précitées puisqu'il faudrait un registre interne 16 bits intermédiaire pour sauvegarder SP.

Une liste de pointeurs d'exécution est ensuite assimilée à...une liste chainée.

Le monde PC était également très éloigné du "pré-carré du CPC" avec CP/M et DOS+.

Un vrai vent de fraicheur qui sentait bon la lavande !

D'autres erreurs ?

Malheureusement oui.

Je n'ai pas fait le tour de toutes les erreurs pour limiter la taille de mes articles.

Plusieurs anciens m'ont remonté des anomalies ou contextualisations étonnantes les concernant dans l'ouvrage.

Qu'ils me pardonnent si je n'ai pas eu le temps de tout analyser et de tout évoquer.

Je n'ai également pas vocation à corriger l'intégralité de l'ouvrage, notamment car il contient déjà une masse de ragots, de potins et d'insinuations inutiles.

Il est bien dommage que le boycott volontaire des sources fiables d'information soit à l'origine d'un tel massacre général.

Nous verrons prochainement comment l'auteur a abordé le phénomène du piratage de jeux sur le CPC, et les conclusions qu'il en a tiré...

Longshot / Logon System

Dans ce billet, je vais évoquer plusieurs erreurs que j'ai vu passer dans le roman "Memory Full", qui prétend relater une histoire de la demoscène CPC.

Je vais évoquer un florilège non exhaustif d'erreurs diverses qui émaillent l'ouvrage et qui auraient pu être évitées...

Je vais évoquer dans ce billet les Euromeetings, le rip des musiques, les premiers graphistes, la naissance du 664+, les CRTC ésotériques et les mystérieux minitels. Et concernant Logon, la constitution de l'équipe, les relations avec Amstrad France et le fanzine Logonies.

Enfin, je vais évoquer la genèse de la technique ultime pour l'auteur.

Euromeeting 1991

Suite au meeting qui a eu lieu à Osnabrück en Allemagne les 27/28 juillet 1991, une démo commémorative a été créée...

Nous étions cinq. L'auteur oublie de citer Poum et Maestro, qui ne comptent pas pour du beurre, même si Poum est cité un peu plus loin dans le chapitre.

Poum avait réalisé une des musiques avec le logiciel qu'il avait écrit (Equinoxe). La seconde musique dans la 2ème partie a été réalisée par Maestro, du groupe Crusaders sur Atari ST, que j'avais eu l'occasion de rencontrer.

Durant le meeting, un clavier avec un éditeur était en libre service afin que chacun puisse venir laisser un message qui ferait partie du scrolling texte. Etant donné la taille du texte final (13 kb), j'avais ajouté une touche permettant de déplacer le pointeur sur le texte du scrolling entre des "smileys" de séparation.

Il existe très peu de photos de l'évènement, mais en voici quelques unes :

Une tradition courante chez les Allemands était la signature de tee-shirts...

Je termine ce petit chapitre sur l'Euromeeting 1991 avec une pensée pour Alain Massoumipour (alias Poum) qui nous a malheureusement quitté en 2019. Il apparait les bras croisés à gauche sur la photo de groupe sur le chemin.

Pour ceux qui l'ont connu, c'était un vrai passionné du CPC, et un de ses plus grands tours de magie, avec quelques autres personnes, a été de grandement contribuer à l'émergence de la scène démo française du CPC.

Le compte est bon...

La composition des groupes de démo de l'époque a très souvent varié, même si celle de Logon a été relativement stable.

Il faut bien le dire, les décomptes dans l'ouvrage sont assez rébarbatifs et assez inintéressants.

Le lecteur ne peut pas identifier ces différents acteurs, noyés au milieu de tonnes de pseudos, de noms de groupes et de transferts divers. Et cela se ressent encore plus nettement à la fin de l'ouvrage.

Pourtant, des interviews, même courtes, aurait humanisé ce dictionnaire des techniques autrement qu'avec une approche basée sur des comparaisons et des ragots divers.

Je ne sais pas pour les autres groupes, mais concernant Logon, l'auteur a finalement perdu le compte et a disserté pour on ne sait trop quelle obscure raison sur l'appartenance "officielle" de certaines personnes au groupe...

Aussi je me permet de rectifier ses propos.

Huit. Eros n'a pas fait partie du groupe avant 1991. Et Overflow a intégré le groupe moins d'un an après.

Neuf.

Dix (Kdo) et Onze (Eros)

Je ne sais d'ailleurs pas qui "m'a conduit" à dresser cette liste, et pourquoi ?

Selon l'auteur, je n'aurais jamais confirmé la présence de KDO dans le groupe...

Extrait d'une interview réalisée par Little Lelex pour Croco World N°7 ou j'ai évoqué le sujet:

Il est vrai que les vampires ont tendance à avoir plusieurs vies dès qu'on leur apporte un peu de sang frais...

Et après ça l'auteur clame qu'il n'avait pas besoin de me poser des questions...

Je fais sans nul doute partie de ceux qui ont "contribué indirectement" ou "sans le savoir" (page 6) mais surtout "bien malgré eux" !

De là à me demander une préface...🙄

EuroMeeting officieux!

Officiel ou officieux ?

Il faut saisir la nuance car ça a l'air vraiment important pour l'auteur tellement il en a inondé l'ouvrage ! 🙄

Petit florilège :

Le premier Euromeeting formel et officiel qui a eu lieu sur CPC s'appelait "The Amstrad Masters Convention #1".

Il n'a pas été organisé à Paris, mais à Stains, et c'est grâce à l'aide de l'incroyable maman de Fred Crazy que nous avons pu gérer une telle logistique (transports, nourriture, hébergement, ...). 💪

Tous les meetings étaient officiels puisque toutes les personnes connues étaient invitées. Ce premier meeting était donc un meeting européen puisque tous les étrangers identifiés début 90 y étaient invités et c'est ainsi que deux allemands ont fait le déplacement. Cela avait d'ailleurs été relaté dans Amstrad 100% de septembre 1991:

Il y aura plus de monde en 1991 en Allemagne, et encore plus en 1992 à Reims. Le meeting de 1992 sera d'ailleurs médiatisé dans 3 pays.

Précisons que c'est BMC qui a organisé le second évènement en 1991 et non DSC (qui semble être une fusion mutante entre BMC et BSC...).

Logon n'a jamais cultivé l'élitisme et le culte de la personnalité : Toute personne intéressée par le CPC (et même au delà du CPC) était conviée à nos meetings et pas seulement les "pointures de l'époque" comme l'écrit l'auteur.

Il semble regretter de ne pas avoir participé à ces premiers meetings. Mais à l'époque, il lui aurait fallu être accompagné d'un tuteur légal pour participer, et nous n'avions pas prévu de nounous pour garder les jeunes participants...

Amstrad France

Les relations de Logon System avec Amstrad France...

Amstrad France ne s'est jamais intéressé aux démos.

L'auteur se trompe de crémerie.

La séquence de délockage de l'ASIC n'a jamais été jugée inviolable, et certainement pas par Alan Sugar, qui est tout sauf un technicien.

C'est l'usage de la séquence elle-même qui était protégée par un brevet :

Le journal anglais Amstrad Action expose d'ailleurs le sujet en mars 1992 :

En ce sens, Alan Sugar pensait peut-être avoir le même poids que Nintendo, qui imposait que les éditeurs de jeux obtiennent un accord pour toute nouvelle licence. En somme, une classique histoire de grenouille et de boeuf...

Si ce brevet pouvait potentiellement tenir la route juridiquement pour les productions réalisées pour la console GX 4000 (à cause du support cartouche), c'était un peu plus confus concernant les CPC+ car on ne peut pas réellement empêcher une personne d'utiliser les capacités de sa machine si il en fait un usage privé.

C'est pour cette raison que le risque a été pris par la rédaction de publier les premiers articles dévoilant la séquence et les caractéristiques techniques de la machine à partir du numéro 38 de Amstrad 100% en juin 1991.

Pour revenir à la séquence, Digit n'a pas fait que la trouver !

Car cette seule opération n'aurait pas été concluante auprès de Amstrad France.

Il avait préparé à l'avance une démo affichant des barres de couleurs énormes avec les 4096 couleurs qui tournaient en fullscreen, en prévision de l'accès à la page "magique".

Aussi, contrairement à ce qu'affirme l'auteur en page 80, Syntax Error ne sera pas le premier à montrer une démo sur le CPC+, puisque la démo de Digit a tourné durant l'exposition devant le staff de Amstrad France.

Bien sûr, nous ne pouvions pas deviner en 15 minutes le fonctionnement de la page ASIC. En réalité, nous disposions déjà de quelques informations techniques:

Le 27 juin 1990, Amstrad France avait convié la presse "CPC" a assister à la présentation de la machine avec un embargo de l'information fixé au 21 août 1990. Le dossier de presse encapsulait une copie de la présentation générale réalisée par Roland Perry, accompagnée de la version 1.4 (12 mars 1990) des spécifications techniques des machines.

Robby, de la rédaction de Amstrad 100%, avait assisté à cette présentation et m'a communiqué les documents dès qu'il en a disposé afin que je lui donne mon avis sur les "Plus".

La seule chose qui nous manquait alors était le moyen d'accéder à la page des entrées/sorties de l'ASIC. Le document, sur ce sujet, était assez évasif :

Digit ne va d'ailleurs pas s'arrêter là, puisqu'il va profiter de l'accès à la machine pour récupérer le contenu des roms du jeu Burnin Rubber, afin d'en extraire les musiques qu'il intégrera ensuite dans sa partie de The Demo.

Pour terminer sur ce sujet, il est étrange d'écrire que le projet de création d'un BASIC n'a pas "abouti en raison du flop commercial à venir de la machine". Facile à dire avec 30 ans de recul...

En réalité, après une discussion avec Victor Perez, j'ai décliné cette proposition car si écrire un jeu est bien plus complexe qu'une démo, écrire un langage interprété est encore bien plus complexe qu'un jeu. Autrement dit, c'était un travail énorme qu'aucun de nous n'aurait pu fournir rapidement.

Il n'est pas toujours bon de mélanger les domaines (comme dans ce roman).

Lors de l'AE90, je connaissais donc les spécifications techniques complètes de la machine depuis plus de 4 mois. Mon pronostic était somme toute assez pessimiste sur le devenir de cette machine au regard des caractéristiques de la concurrence, et même si la machine s'est quand même assez bien vendue en France.

Aussi, dès septembre 1990, après la fin de l'embargo technique, j'ai commencé à envoyer des copies de la documentation technique un peu partout, et surtout vers les allemands qui étaient très demandeurs.

Cela a permit à quelques uns de sortir leur "première" production sur la machine qu'ils venaient d'acheter, mais c'est une autre histoire...

Logonies

Un fanzine interne ? Certes...

Cependant, sans en avoir lu un exemplaire, l'auteur en imagine le contenu et le pose comme un fait établi :

Le fanzine n'avait pas vocation à apprendre des techniques, puisque nous les partagions déjà avec tout le monde et entre nous.

De plus le 1er numéro de ce fanzine date du 9 septembre 1992 (presque 2 ans après la sortie de The Demo) !

Lorsque c'était le cas, les échanges techniques avaient lieu en "live", au resto (on avait notre "cantine" à l'époque) ou à domicile. Il faut arrêter de croire que les choses sont compliquées à comprendre sur un CPC lorsqu'elles sont expliquées simplement.

L'unité du groupe tenait à l'amitié qui était née de nos rencontres très régulières et de notre passion. Et ça, bien sûr, l'ouvrage ne peut pas le décrire puisque l'auteur considère que sa conception de la démo, c'est surtout de la souffrance solitaire dans l'objectif de recueillir les fruits de son mérite.

Music Rips !

L'extraction du code des musiques de jeu était un sport prisé.

L'auteur fait de nouveau fonctionner son imagination ...

Bien au contraire, la musique était la chose la plus facile à extraire, car c'était pratiquement toujours un bout de code isolé compact avec ses données fourni par le musicien et ajouté par le codeur du jeu et qui était très souvent appelé 1 fois par frame.

En général, le musicien plaçait 3 points d'entrée au début du player (init, play, stop) et qui étaient très facilement identifiables.

La seule "difficulté" consistait à déterminer jusqu'à quelle adresse la musique était stockée. C'était assez facile de s'en rendre compte une fois qu'elle était isolée. Au pire, on avait parfois plus de données que nécessaire...

Graphist or not Graphist ?

L'auteur s'interroge sur l'intégration de graphistes ou musiciens dans les groupes...

L'art de dire une chose et son contraire 2 pages après...

664+ stéréo ! 🤣

Naissance d'une machine fabuleuse qui faisait la fierté de Alan Sugar...🧚

Le 664+ est également équipé du CRTC 7 mais il est toutefois moins puissant que le CPC 5512+ en dolby surround ou la GX 4006 (mais en mono...).

Mais qu'ont fait les relecteurs ??? 😱

On se demande bien qui sont ces "autres" que l'auteur évoque et qui auraient "souligné" une telle chose ?

Je n'ai jamais entendu personne parler de ça, et surtout cela démontrerait de grosses lacunes en électronique.

"C'est bien mal connaître l'histoire des bornes d'arcade que de s'étonner de la différence de fréquence des circuits environnant le Z80A."

L'auteur aurait cependant pu souligner le déséquilibre notable concernant la mémoire de 64 k, voire la création d'un modèle 464+ avec un lecteur de cassettes. J'avais évoqué le sujet dans Amstrad 100% N°41 :

Soupe de CRTC !

Après le CRTC 7, les types A et B sont évoqués dans l'ouvrage....

Gozeur, dans sa documentation CRTC, avait surinterprété certaines informations et ajouté un peu de confusion en ajoutant R6/R8 dans cette histoire de sous-types.

La plupart des "retours" sur ces sous-types n'avaient donc rien à voir avec la démo de strooki et étaient plutôt en relation avec la rupture verticale.

Offset a repris ces sous types dans Quasar N°11 sans la mixture R6/R8 en invoquant la rupture verticale et les changements de mode graphique. D'ailleurs, ces anciennes informations erronées ont été reprises telles quelles pour une démo récente... 🙄

Il n'existe sur CPC que les CRTC 0 à 4 décrits dans le Compendium.

L'étude du CRTC 1 a cependant permis de constater qu'il existe une petite différence de comportement entre deux circuits (1A / 1B). Cette différence est peut-être liée à une tolérance et une vitesse d'écriture dans un registre sur un évènement précis.

Anachroniks : Du Minitel à Internet !

L'auteur livre ici une vision assez "idéalisée" de ce qu'était un minitel...

Il croit que les boites aux lettres sur minitel n'existaient pas avant 1991 alors que le minitel a débarqué dans les foyers en 1980 ? 🤪

Déjà depuis 1985 au moins, dès que deux personnes s'étaient contactées par courrier ou par téléphone une première fois, elles pouvaient échanger des messages sur des boites aux lettre. Cependant, ce n'était pas gratuit!!

En 1988 il existait 3615 AMCHARGE et 3615 RTEL (et son équivalent RTEL2 en 3614, moins onéreux). En 1989 j'échangeais déjà avec Fefesse sur RTEL, par exemple.

L'auteur semble également croire que le minitel permettait d'échanger des fichiers puisqu'il met en comparaison le coût d'envoi des disquettes avec le coût du minitel. 😂.

C'était possible uniquement avec le 664+ monochrome.

Le minitel marginal en 1990 ? 🤣

Si des solutions ont existé pour permettre de récupérer des fichiers sur des serveurs (comme Amstrad 100% l'a fait avec son kit de téléchargement), ce n'était pas de l'échange de fichiers entre 2 personnes, puisqu'il fallait disposer d'un serveur hébergeant quelques maigres contenus dans un format donné. D'autant que ça rendait la chose difficile avec les jeux protégés.

Vous la sentez la petite différence générationnelle ?

Apprentissage

L'auteur pense que les demomakers se formaient grâce à Amstrad 100% ou dans CPC-AI en Allemagne, et les équivalents dans les autres pays.

Si de nombreuses personnes ont profité des articles techniques dans Amstrad 100%, la majorité des demomakers déjà actifs de l'époque n'avaient pas besoin de lire ces articles, puisque ces techniques étaient échangées par courrier, et que rien n'est vraiment complexe.

Si le terme "rupture" est devenu "universel" sur la scène CPC bien avant les premiers articles dans Amstrad 100% sur le sujet (avril 1991), c'est bien que les allemands et les autres européens recevaient l'information autrement, quand ce n'étaient pas des échanges directs en meetings.

Il est indéniable que la scène démo CPC a démarré bien trop tard et il était difficile de la faire grossir le plus possible avant la mort commerciale de la machine, qui a entrainé la désertion d'une majorité des utilisateurs.....

Génèse de LA technique

Si il est bien une technique qui met l'auteur du roman en pâmoison, c'est la technique que Overflow a nommé rupture verticale.

C'est inexact.

A l'origine, j'avais nommé cette technique "rupture horizontale" car cela me semblait plus logique. Mes premiers essais remontent à février/mars 1990.

Après la rupture ligne à ligne en octobre 1989, c'était (une fois de plus) la suite logique.

Mon objectif initial était de changer de mode graphique en cours de ligne.

Je pensais que le logiciel graphique Quantum (1987) sur ATARI ST y parvenait (j'ai compris plus tard qu'il s'agissait en fait de splitrasters qui m'ont fait croire que 2 modes coexistaient de part et d'autre de l'écran).

⚠️ Je supposais avoir besoin d'une Hsync en cours de ligne pour y parvenir, mais j'associais, à tort, la survenance de la Hsync à la rupture, et j'ai donc attaqué le sujet directement en réduisant la taille des lignes avec R0. 😵‍💫

⚠️ J'avais réduit la longueur de Hsync à 2 (CRTC R3) et observé que le mode graphique changeait à partir de 2 µsec minimum de Hsync. Je ne pouvais pas savoir à l'époque qu'avec R3=2, le Gate Array n'envoyait (presque) plus de signal Csync vers le moniteur sur les lignes concernées, et mon écran commençait à partir en distorsion au bout d'une quinzaine de lignes. J'ai testé quelques combinaisons de R0 non multiples de 64 pour changer l'offset et constaté l'émergence de nouveaux problèmes de compatibilité CRTC.

Rentrant dans la vie active pour mon premier job, j'ai arrêté ce travail afin de consacrer mon temps libre à The Demo et au groupe.

Courant 1990, j'ai soumis le sujet de l'augmentation du nombre de "blocs" et du changement de mode graphique aux autres membres de l'équipe à partir de mes travaux préliminaires.

Fin 1990, Fred Crazy avait par exemple commencé une investigation via le mode interlace IVM (CRTC R8=3). Ce n'était pas en soi une mauvaise idée, mais avec le recul, pas avec les bases de l'époque.

En janvier 1991, Overflow, laissant Fred investiguer sur la gestion R8, est reparti sur l'idée de la rupture "horizontale", et a produit ses premières avancées significatives en mars 1991. Il avait réussi à régler en grande partie les problématiques de synchronisation avec une ruse de sioux. Nous comprenions cependant toujours mal le fonctionnement de la Hsync.

⚠️ Avec R3=0 il "supprimait" la Hsync sur CRTC 0 et "l'annulait une fois débutée" sur CRTC 1. Le cul bordé de nouilles ! 😂

La brillante mise au point de la technique de RVI donnera naissance à S&KOH.

C'est finalement Duncan qui va nous éclairer sur le "fonctionnement" de la Hsync en août 1992 pour permettre un changement de mode graphique facile et précis. Ca semblait carrément évident mais comme pour toute chose, c'est toujours très facile de le dire après, surtout lorsqu'on n'a pas un Shap à portée de main.

En définitive, l'investigation de plus en plus précise et poussée des CRTC a multiplié l'apparition des différences de fonctionnement interne (et il y en a!).

Si disposer de plus de ram vidéo vectorisable grâce à la rupture en utilisant ces techniques est parfois intéressant, cela peut parfois la circonscrire à des effets bien précis à cause de sa consommation CPU, ou même la limiter à certains circuits lorsque l'adaptation n'est pas faisable pour de vraies questions de fond...🤣

Tout comme pour les ragots, jamais 2 sans 3...

A bientôt...

Longshot / Logon System

🇬🇧 English version

Cet article, dans la continuité du précédent, fait l'étude de "Memory Full", un livre qui prétend décrire l'histoire de la demoscene CPC.

Je vais évoquer un florilège non exhaustif d'erreurs diverses qui émaillent l'ouvrage et qui auraient pu être évitées.

Je vais évoquer dans ce billet les erreurs faites sur quelques démos (Logon 3, Révolog, Amazing, Yao, Armaxess, KKB First, 5KB 3) en commençant par les tendances artistiques de la fin des années 80...

Trash design

L'auteur évoque l'influence "hard rock/heavy metal" sur les graphismes des démos de la fin des années 80, début des années 90.

On ne voit pas très bien dans quelles démos il est allé chercher ça, puisque les rares graphistes qui participaient à des démos n'étaient pas vraiment attirés par ce genre de musique.

Le crâne dessiné par Brad pour The Demo, par exemple, n'est pas du tout lié à une influence hard rock, tout comme les nombreux dessins que Zebigboss et Hightower vont produire durant leur période d'activité sur CPC pour Logon.

L'auteur ne s'arrête pas en si bon chemin... Après les graphismes... La musique !!

On sent bien l'influence hard rock dans 'Oh mummy' et 'Cybernoid 2', et finalement dans à peu près tous les programmes écrits sur CPC 😂

Logon Demo 3 : Erreur de CRTC...

Il s'agit ici d'une petite coquille, mais qui permet d'évoquer avec vous les problèmes de compatibilité entre les CPC...

C'est sur les CRTC 1 et 2 qu'un problème de compatibilité s'est posé et non le CRTC 0, puisque c'était le circuit qui équipait mon CPC.

Même si ce CRTC 0 est moins facile à "maitriser" qu'un CRTC 1, c'est bien ce circuit qui a d'abord été privilégié pour les démos. Pour l'anecdote, j'ai rencontré des amateurs de démos qui avaient échangé leur machine pour pouvoir disposer de ce CRTC à l'époque.

J'ai été très déçu de voir ma démo 3 bugger sur d'autres CPC, mais pas forcément surpris car ces problèmes de compatibilité existaient sur d'autres plateformes, comme par exemple le circuit vidéo des premiers ATARI ST ou les cartes graphiques des PC, et en particulier les PC1512 et PC1640 de Amstrad.

Je me suis rendu compte du problème de CRTC de cette "démo" dans un magasin d'informatique ou travaillait à l'époque mon meilleur ami (R.I.P Claude RAOUX, auteur de l'outil disque Udisk) et à qui j'avais montré mes démos. La surprise était d'autant plus grande que le "truc de répétition de ligne utilisé" fonctionnait bien en Basic sur toutes les machines.

Il était alors difficile de se rendre compte de l'importance du problème, et à quoi il était lié. Car si il peut paraitre évident de nos jours que c'est une différence de CRTC qui est à l'origine des problèmes de compatibilité, ça ne l'était en fait pas du tout, car certains problèmes aurait très bien pu avoir d'autres origines. J'ai par exemple indiqué dans un article précédent que les problèmes du mode "interlace" sur CPC ne sont pas liés au CRTC, mais au GATE ARRAY.

Le jeu Crafon & Xunk, écrit par Rémi Herbulot, contenait un test CRTC rudimentaire. Pour l'anecdote, j'avais amené le jeu craqué chez un ami et j'ai été surpris de ne pas voir le scrolling transitionnel entre les écrans sur sa machine, alors que ça marchait très bien chez moi. J'ai été encore plus surpris lorsque j'ai viré le test pour forcer le scrolling sur sa machine et que j'ai vu que ça marchait très bien. Le test éliminait 2 CRTC et considérait que le CRTC 1 était aussi un CRTC 2.

Depuis l'affaire Appolo 13, ces deux CRTC ont divorcé...

Revolog : Protégée ?

L'auteur pense que la démo Revolog a été diffusée de manière protégée et que ça faisait partie de ses caractéristiques...

La version publique de Revolog n'a jamais été protégée.

Mon objectif était de propager les techniques, pas de faire l'inverse.

C'est un peu comme si l'auteur d'un fanzine disque le protégeait avec un format incompatible au niveau disque et au niveau CRTC avec de vrais CPC, et illisible par la plupart des émulateurs... Ce ne serait pas très malin !!!!

J'ai protégé une version de Revolog spécifiquement destinée à Rubi car il m'avait envoyé sa protection dans nos premiers échanges pour que je la teste. Je voulais tenter cet exercice, après avoir si longtemps fait le contraire, et je n'ai rien trouvé de mieux que la démo que j'avais sous la main.

Mais Rubi a amené sa version à la rédaction de Amstrad 100% et elle s'est propagée en parallèle de la version officielle.

Ce que ne raconte pas l'auteur, c'est si cette protection est restée inviolée, puisque personne n'a jamais revendiqué y être parvenu...

L'explication technique donnée par l'auteur concernant la méthode que j'ai employé pour crypter la démo est un autre fake.

Je n'ai jamais utilisé la mémoire interne de la Multiface II (créée en 1986 😂 ) pour y loger quoi que ce soit. L'encart qui suit explique comment cette protection a été réellement créée :

Ces propos de l'auteur envers "Famous Cach" n'avaient rien à faire dans un tel ouvrage.

Rubi n'a rien "admis" car il ne savait pas comment la démo était protégée.

Il a déduit tout seul que la protection ne pouvait être cassée que grâce à une cartouche hardware, et il m'a juste indiqué l'adresse du 2ème octet du JR. 😮

Amazing Demo-Déluge de Fakes !

Chargement statique...

Selon l'auteur du roman rien ne bouge à l'écran pendant que la démo charge...

Il compte pour du beurre, le compteur géant qui compte les kilos lus ?

Détection CRTC

Oui...encore!

Selon l'auteur du roman, il a fallu attendre The Demo (1991) pour que le CRTC soit testé :

Une image valant plus que mille mots, voici l'intro de Amazing Demo sortie en janvier 1990, un an avant The Demo :

Raccourcis sur les ruptures !

L'auteur a pris beaucoup de temps pour faire la genèse de certaines techniques.

Pour la technique de rupture, utilisée aujourd'hui dans pratiquement toutes les démos, il oublie une étape logique dans son évolution.

L'étape qui est passée à la trappe permet pourtant de comprendre l'évolution logique des techniques de rupture, qui sont tant déclamées dans l'ouvrage.

Jusqu'alors les écrans utilisaient toujours une seule rupture dans le frame. Pour le profane, c'est un peu comme si les démos (ou pratiquement tous les jeux) précédents affichaient tous seulement 2 zones différentes sur tout l'écran.

Comme on peut le voir sur l'image plus bas, la première partie de Amazing Demo présente de nombreux scrollings différentiels. Il fallait comprendre la logique du frame pour augmenter le nombre de zones sur un écran. D'un point de vue technique pour cette partie, cela consiste à positionner CRTC R4=0 pour créer plus d'une rupture de plusieurs lignes chacune (zones) par frame (écran).

Cela permet l'affichage de 17 scrollings de 8 lignes animés avec 3 vitesses différentes. Cette étape est importante pour comprendre la suivante, qui consistait alors à abaisser également le nombre de lignes par caractère à 1 (CRTC R9=0) et obtenir des zones de une ligne, qu'on appelle aujourd'hui communément "Rupture ligne à ligne". Rien de plus logique !

Switch Animation

Le principe d'un effet non négligeable existe dans la première partie et a été totalement ignoré par l'auteur.

Comme on peut le constater sur l'image ci-dessous, les textes mentionnant "Logon System" et "Malibu" se déforment en ondulant en même temps qu'ils se déplacent horizontalement (voir la ligne numéro 5 violette) :

Cet effet utilise le principe de ralentissement d'un scrolling hardware basé sur le "switching" de page, introduit dans "Longshot démo".

Ainsi, au lieu "d'injecter" un caractère seulement décalé, on lui applique une transformation. Le nombre de pages alternantes fixe ainsi le nombre d'étapes d'animation appliqué au motif (ici des caractères). Ainsi, plus le scrolling est "lent" plus il est possible de créer des étapes d'animation.

Ce principe sera réutilisé par la suite dans quelques démos sous diverses formes.

En mode graphique 16 couleurs ?

L'auteur trouve Amazing Démo si colorée qu'il croit qu'elle est en mode graphique 0 :

"Amazing Demo" est intégralement en mode 2 et en mode 1, à l'exception de 2 petits logos.

L'introduction de P007 était en mode 0, mais n'appartient pas à la version officielle et ne représente de toute manière pas l'intégralité de la démo.

Ruptures by Naminu

L'auteur pense que les parties de Naminu réalisent des scrollings hardware...

Naminu n'était pas à l'aise avec la rupture et s'intéressait davantage à la 3D ou au AY. Il y a une seule partie avec une rupture.

Ses scrollings n'étaient pas "hardware", pas plus que dans la Malibu démo 4 d'ailleurs.

Amazing Drama...

"Don de soi", "trahison", "conflits" et "élimination"... 🙄 (soupir)

Sortez le pop corn ! Il est ici question de l'introduction réalisée par P007.

L'auteur semble admirer tellement cette démo qu'il pense qu'elle était une consécration qui méritait bien son petit drama (encore un!) et un petit agacement :

On l'a déjà vu, écrire que Fefesse était mon "concurrent" est un fake.

Ecrire que j'ai "supprimé" la partie de P007 lorsque j'ai réédité "Amazing Demo" en 2021 est également un fake. L'auteur, qui prétend avoir discuté avec moi (ou même avec des personnes ayant eu cette démo à l'époque), semble avoir la mémoire courte...

Il y a eu deux versions de "Amazing Demo" en 1990.

C'est malheureusement la version la moins diffusée qui a atterri sur Cpc Power.

"Amazing Demo" était prête à sortir fin 1989. J'attendais à l'époque une introduction que devait écrire P007. Sa partie était bâclée. Le problème que cela posait était surtout les "fuckings" et insultes contenues dans les textes.

On voit ce que donnent ce genre de textes, encore de nos jours...

Les tous premiers retours de "Amazing Demo" ont été catastrophiques, à cause des incompatibilités CRTC mais aussi à cause d'un format de 19 secteurs/pistes.

J'ai pris la décision de faire une seconde version avec 17 secteurs/pistes sans l'introduction avec les textes d'insultes, que j'ai renvoyé à tous mes contacts.

Fin 2021, je suis reparti de la version officielle en ajoutant une introduction présentant un nouvel effet et de nouvelles techniques afin d'introduire le Compendium, un document technique sur l'architecture vidéo des CPC.

Faisant preuve de la même intégrité journalistique dont il se targue dans son ouvrage, l'auteur va dénigrer en mars 2022, de manière "ironique" et mensongère cette nouvelle introduction dans sa démo OSC#2, tout en passant sous silence la sortie du Compendium.

Scrollings en splitrasters

L'auteur pense que la démo 3 de GPA est la première étape vers une technique de "split rasters mobiles".

La première démo à avoir déplacé un splitraster date de septembre 1989.

Il s'agissait de la partie Phenomena pour la future démo 5 de Malibu, programmée par Naminu (que j'ai découverte lors de l'Amstrad Expo 89).

Phenomena est sortie seule et également comme une partie de The Amazing Demo avec des textes différents. La "End Part" de Amazing Demo utilise un effet similaire que j'ai honteusement imité :

Si on cherche à décrire une "progression technique", la phrase suivante est donc incorrecte, surtout si on s'attache à prioriser chaque chose :

On aurait donc plutôt du lire :

Démo interactive

Toujours à propos de la GPA Demo 3, l'auteur croit que c'est cette dernière qui a lancé la "mode" de l'interactivité des démos :

C'est encore inexact. Décidément.

On ne voit pas trop ou est la "prouesse" mais Naminu avait néanmoins initié cette "mode" dans sa démo "Phenomena" (ci-dessus) mais également dans la partie "Cool Demo" de Amazing Demo, en gérant des compteurs "validés" et va d'ailleurs récidiver dans "The Demo".

Quitte à décrire ce type de "défi", on pourra s'étonner que la mode des scrollings textes les plus longs, héritée de l'Atari, soit passée sous silence.

Yao Demo

N'oubliez pas que l'auteur a une conception high-level des démos CPC... Au sujet des musiques de la Yao demo, il écrit :

C'est à se demander si l'auteur a lancé cette démo ?

Voici les musiques CPC utilisées dans Yao Demo :

Il n'y a pas de "retard" de Fefesse, car il n'y avait aucune "course" ou "compétition" entre nous.

La dernière partie de Yao Demo joue la musique du jeu "Thrust" que j'ai transféré d'Atari ST.

Fefesse l'écrit dans son scrolling et m'avait demandé si il pouvait la mettre dans sa démo, ce que j'avais bien entendu accepté. Je ne me suis jamais senti "propriétaire" de la dite musique, que j'ai juste portée sur CPC.

L'auteur va faire une comparaison péjorative de la démo de Fefesse avec le jeu "Mission Genocide" (jeu cité 12 fois dans l'ouvrage!).

Bref, l'écran scrolle vers le bas (et non vers le haut).

Dans Yao demo, on peut également voir un scrolling horizontal qui se déplace verticalement en utilisant une table sinusoïdale :

Rappelons qu'être le "premier" n'a que peu d'importance, surtout quand tout est comparé avec des techniques utilisées dans des jeux.

D'autres démos avaient déjà fait ce type de scrolling. Le type de rupture n'a absolument aucune importance, même si je préfère celles qui sentent la lavande. Bref, cela existait au moins déjà dans la partie Megaraster de Amazing Demo que l'auteur est précisément en train de comparer avec la Yao Demo...🤪

Armaxess Demo

Rappelez vous....

Il s'agit de cette démo "culte" que j'évoquais dans un précédent billet et qui est prise en référence assez souvent alors que personne ne l'avait vue. 🤣

L'analyse technique qui en est faite dans l'ouvrage est d'ailleurs inexacte...

Le scrolling de cette partie n'est pas hardware mais software.

Il est ralenti au demi octet grâce à un page flipping.

KKB First

En page 62, l'auteur consacre un gros chapitre pour décrire la "technique" derrière l'écran d'introduction de la démo KKB First.

Il avait probablement extrait de son document, en cours d'écriture, le contenu de ce chapitre pour le glisser dans le fanzine 64NOPS N°1.

N'ayant pas compris lui-même comment la couleur d'un splitraster pouvait "changer aussi vite", il avait alors inventé de toute pièce une légende urbaine dont il n'a jamais démontré la réalité:

Dans la première version de son article, il apportait une réponse technique farfelue à cette question jusqu'à ce qu'il en soit détrompé, montrant qu'il n'était pas allé voir par lui-même.

Au lieu de retirer tout le chapitre dans son ouvrage, il l'a tout de même conservé en continuant de considérer que la technique employée "plaçait les codeurs [de l'époque] devant une apparente impossibilité technique" (page 63).

Ainsi, il pense que si lui n'a pas compris une chose, c'est que ça doit être trop compliqué pour les autres. Au point d'imaginer que les codeurs "impressionnés" sont restés des années sans comprendre ce qui se passait, et surtout sans aller voir dans le code si ils estimaient être devant "l'astuce" du siècle...😂

N'oublions pas tout de même le nombre de personnes qui ont décortiqué la technique de scrolling hardware vertical de "Mission Genocide"...

Pour revenir sur KKB First, l'auteur devrait pourtant savoir qu'une appréciation de démo est subjective et que son avis ne fait pas autorité (même si il le croit).

KKB First était certes une démo intéressante grâce à ses enchainements, mais elle souffrait de graphismes assez passables, et pas seulement parce qu'elle est faite pour être regardée sur un moniteur monochrome.

On s'interrogera d'ailleurs que l'image d'illustration ait été faite à partir d'un moniteur couleur sélectionné avec l'émulateur Winape.

Afin de donner corps à cette comparaison douteuse, l'auteur s'amuse à faire une distinction entre une "onescreen" et une méga-demo (comme Yao ou Amazing) pour éviter de les comparer. Cette distinction est grotesque puisque les méga-demos de l'époque étaient des groupements de "onescreen" sans aucun rapport entre elles.

On peut donc tout à fait comparer cette démo avec des parties de méga démos.

Et en réalité, la dernière partie de la Yao Demo ou la partie Mega17 de Naminu dans Amazing Demo étaient toutes aussi scénarisées et plaisantes à regarder :

Ici encore, rien n'est justifié. Ce sont des affirmations gratuites.

Qui sont donc ces personnes qui, à l'instar de l'auteur, ont jugé cette démo surestimée à l'époque ou ne présentant aucune nouveauté ?

L'auteur va ensuite se servir d'un extrait choisi d'un texte de Elmsoft pour en faire une nouvelle généralité :

Les propos sont sortis de leur contexte, puisque Elmsoft introduit son texte par "IT'S A JOKE CASE SOME MEMBERS OF LOGON SYSTEM FAIL TO REALIZE THAT...". L'auteur semble avoir zappé ça....

Je suis curieux de connaitre les "nombreuses démos" qui faisaient cette comparaison fréquente entre "KKB First" et "Amazing Demo"... 🥵

5KB DEMO 3

Cette démo n'a jamais été terminée... Il est utile de le rappeler...

C'est ballot, mais Bittlejuice n'a jamais fait partie des 5KB.

Et ils ne connaissaient pas ce dernier avant l'Euromeeting 92...

Surtout sans avoir demandé à ceux qui savent...😬

L'auteur ne connait pas l'histoire de cette démo, ni même la tête qu'elle avait avant que Bitteljuice ne refasse quelques dessins, ou même le rôle que j'ai pu jouer.

Après tout, il est capable d'écrire un roman en se basant sur quelques articles, la météo, des scrollings texte et des récits d'adolescents...Il n'est plus à ça près.

Et lorsqu'il va évoquer le loader musical de cette démo :

Super sympa pour les deux codeurs.

L'auteur n'aime sans doute pas patienter pour charger une démo, mais une fois encore, le contexte de l'époque est totalement passé à la trappe. Cette époque ou les gens prenaient le temps de lire un scrolling de 2 heures et taper patiemment des pages de listings édités dans les magazines.

Par ailleurs, je ne trouve pas les chargements de 5KB démo 3 si "intolérables" que l'auteur le prétend, et peut-être ne l'a t il pas regardé sur une vraie machine vu que certains screenshots sont réalisés sur une vieille version de Winape...

Enfin, je rappelle de nouveau que la 5KB démo 3 n'était pas achevée et qu'elle fait partie des démos que j'ai contribué à sauver des eaux. Mais ai je tout diffusé ?

Si vous pensez que ce sont les seules erreurs qui jalonnent le roman, attendez de voir la suite...

Longshot / Logon System

🇬🇧 English version

Cet article, dans la continuité du précédent, fait l'étude de "Memory Full", un livre qui prétend décrire l'histoire de la demoscene CPC.

Si certains pensaient qu'il n'y avait ni romance, potins ou ragots dans cet ouvrage, je leur conseille de lire ce billet. Gala n'a qu'à bien se tenir!

La plupart des appréciations dans l'ouvrage sont basées sur des histoires non vérifiées, souvent décontextualisées, et n'avaient pas du tout leur place dans un tel ouvrage car elles n'apportent rien.

Si vous avez lu mes premiers billets, vous devez désormais un peu mieux comprendre pourquoi l'auteur a jugé bon d'en parler à longueur de roman...
Il adore ça!

Interlace fumeux ! (Episode 1)

La "Logon Demo 4" est une démo que je n'ai jamais finalisée pour diffusion. L'auteur mène l'enquête en page 46 :

Si vous avez un peu suivi mon blog, j'ai déjà exprimé l'idée que j'avais des "top ten", "charts" et autres classements méritocratiques chéris par l'auteur. Je l'exprimais déjà en 1991 auprès d'un rédacteur de fanzine :

Je me fous comme de mon dernier "débardeur" des classements et de la paternité des "techniques". Dans le classement que nous avons donné, il ne fallait y voir qu'une manière amusante d'éluder ce "Top 5" car c'était une question récurrente dans certains fanzines.

Tout le monde n'a pas la même conception des choses, même si certains semblent y trouver un moyen d'exister... Pourquoi pas... 🙄

La démo est et reste avant toute chose un amusement. Dans une aussi petite communauté, fixer ce type de classement arbitraire est juste suicidaire...

J'ai souvent expliqué des techniques et démontré qu'elles étaient possibles sans même les avoir exploitées en démo.

Ce n'est pas l'attitude d'une personne qui voudrait revendiquer à tout prix être la "première" à appliquer telle ou telle technique dans une démo.

Le dernier exemple en date est la technique de RFD, qui était expliquée avec son mode d'emploi depuis 2 ans dans le Compendium jusqu'à ce que je finisse par l'utiliser dans la démo DSC 4, parue en octobre 2023.

Cette technique fonctionne pourtant sur le seul CRTC que l'auteur vénère au point d'y consacrer un article de 3 pages. Peut-être que tout ce qui est signé Longshot doit le dégoûter, comme il l'exprimait publiquement ici de manière "ironique" le 30.10.2022

Revenons sur l'enquête relative à la démo 4....

L'auteur vient d'établir une chronologie avec une démo qui n'est pas sortie (et dont il nie plus ou moins l'existence) 😂

Il m'accuse d'avoir trompé les gens en connaissance de cause, ce qui est un nouveau procès d'intention diffamatoire.

Autrement dit, je savais que ma démo ne présentait pas du vrai "interlace" mais j'ai tenté de le faire croire. Pour les profanes, le mode interlace permet en principe de doubler la résolution verticale d'une image.

BSC est un demomaker allemand, qui a publié sa démo 7 après le 21 mars 1989 et croyait que sa démo affichait une résolution verticale de 416 pixels (au lieu de 208) :

Nous pensions que le mode interlace des circuits CRTC 6845 fonctionnait correctement. Et c'est bien le cas, contrairement à ce que Grim et quelques "spécialistes" du CPC ont raconté après les années 2000.

Nous n'avions pas à l'époque les connaissances techniques pour comprendre que c'est un autre circuit, le GATE ARRAY, qui dénature les signaux de synchronisation reçus du CRTC et ensuite envoyés au moniteur.

En terme simple, ce n'est pas la faute des CRTC si l'interlace "fonctionne mal" sur CPC. Pour leur part, ils font parfaitement le job !

Jusqu'au 31 mai 2007, je pensais donc sincèrement que l'effet était bien une image interlace jusqu'à ce que Super-Sylvestre me démontre le contraire.

En juillet 2017, je suis intervenu sur CpcWiki pour détromper BSC qui pensait tout aussi sincèrement que sa démo produisait une image de ce type :

BSC a admis la chose de bonne guerre, comme je l'ai moi-même fait en 2007.

Malgré cette mise au point publique qu'il connaît, l'auteur écrit :

On pourrait s'amuser que l'auteur essaie d'enfumer ses lecteurs de manière aussi pernicieuse, mais c'est assez triste en réalité !

Il doit penser que BSC s'est aussi livré à un enfumage... Sympa pour lui!

Ce dernier doit de surcroît être un "ingrat" selon les standards de l'auteur car sa démo ne fonctionne "correctement" que sur CRTC 2 et sur CRTC 0 (moyennant l'appui sur la touche "Entrée") (la programmation de ce mode dépend du circuit).

Il est certain qu'avec un livre aussi "élogieux" (sic), l'auteur considère vraiment que le demomaking est une "affaire de communication et d'image" !

Interlace Fumeux ! (Episode 2)

L'auteur a décidé de prendre un peu d'avance sur son "tome 2 autobiographique" pour anticiper de nouvelles prouesses...

C'est mieux.... mais pas tout à fait correct non plus.

Mais du coup ? Hicks et Grim sont-ils en train de se livrer à un enfumage, ou est-ce qu'il y a quelque chose qu'il n'ont pas (encore) compris ?

Pour finir ce chapitre (déjà bien trop long) sur la Logon Demo 4, je ne l'ai pas distribué pour une raison simple :

Le mode interlace, qu'il soit bien ou mal réalisé, affiche une image à 25Hz.

J'ai du mal à apprécier ce genre d'image pénible pour les yeux, parfois qualifié sur CPC de "Flashouille" après les travaux de Super-Sylvestre dans le domaine.

J'ai réalisé il y a 2 ans environ des expérimentations en résolution verticale 800 (au lieu de 200) à 12.5 Hz. Ça restera dans mes tiroirs, car c'est juste encore plus pénible. Mais peut-être que j'essaie d'enfumer l'auteur, qui sait ?

La demoscène n'est ni une guerre ni une compétition féroce ou il faut réaliser des "world records" et revendiquer être le premier à utiliser telle ou telle technique.

Si je ne suis pas satisfait d'un code, je ne le sors pas, et c'est d'ailleurs ce qui a failli également arriver à la démo 3 à l'époque vu les problèmes de compatibilité.

Je ne suis pas davantage un objet de collection rangé dans les antiquités, comme le roman essaie de le faire penser, puisque je n'ai jamais vraiment lâché l'univers du CPC.

Celui qui a mauvaise réputation est à moitié pendu...

Lire cet ouvrage s'est révélé pénible tant il est émaillé de racontars divers. Concernant "Cach", un cracker de la fin des années 80, par exemple, il est question d'image de marque, de réputation, de mérite :

L'auteur semble ne pas avoir bien compris que se servir constamment des dires de quelques personnes ne suffit pas à le dédouaner de la présence de ces ragots dans son ouvrage, sans même d'ailleurs que les personnes citées aient leur mot à dire.

Imaginons une seule seconde que tous les pseudos soient remplacés par l'identité civile des personnes concernées et on saisira aisément la portée de ces propos. Le pseudo est-il un passe-droit ?

Si il n'y a aucun problème pour retrouver mon identité civile, car je n'ai rien à cacher, j'ai constaté que ce n'est pas le cas pour tout le monde.... 🙄

Status Quo sur le Plus ?

Quelle allait être l'attitude de Logon face au Cpc+ pour une future démo ?

L'auteur croit le savoir...

Encore... toujours... et encore... du fake...

Chacun était libre de faire (ou pas) une démo spécifiquement pour le Plus, à condition de disposer de la machine.

Pour les productions "old", chacun était libre d'utiliser (ou pas) les capacités du Plus, soit spécifiquement pour ceux qui disposait déjà de la machine, ou de manière cosmétique via des librairies dédiées (affichage de logos prédéfinis, palettes) pour ceux qui n'avaient pas la machine.

Mixture sur le Plus !

L'auteur évoque le B-Asic sans réellement savoir de quoi il parle...

J'évoquerais notre discussion avec Victor PEREZ du staff de Amstrad France dans un prochain billet.

Ce n'est pas "Pict" qui a fait la démonstration mais "Digit".

Pict était bien trop petit pour atteindre un CPC placé en hauteur. 😘

Je n'ai pas développé de BASIC et l'auteur fait une confusion technique. Le B-ASIC est une collection de RSX. Pour le profane, une RSX (Resident System eXtensions) est une instruction complémentaire que le BASIC standard (Locomotive BASIC) permet d'ajouter à ses propres instructions.

C'est parce que la définition de ces instructions occupe peu de place en mémoire qu'il était possible de les publier sous forme de "listing à taper" sur quelques pages du magazine A100%.

Ce n'était en aucune façon des "pré-versions" mais des versions complètes et il ne faudra donc pas "attendre des années pour qu'une première version soit diffusée" comme l'indique à tort l'auteur.

Des lecteurs du magazine ont immédiatement pu réaliser des programmes avec ces instructions complémentaires. J'ai notamment en mémoire un éditeur graphique de"sprite hardware" de bonne facture envoyé par un lecteur.

Avec sa formulation alambiquée, l'auteur laisse croire qu'il faudra des années pour que le B-Asic serve à quelqu'un.

Si le sujet vous intéresse (vous développez sur Amstrad CPC+, par exemple), les versions suivantes ont été publiées dans A100%:

• Version 1.0 publiée dans A100% 38 (juin 1991)
• Version 1.1 publiée dans A100% 39 (juillet 1991)
• Version 1.3 publiée dans A100% 40 (septembre 1991)
• Version 1.4 publiée dans A100% 42 (février 1992).

Je vous conseille néanmoins la version 3.4 (24 mai 2007) qui est la plus complète existante à ce jour.

Elle est disponible ici : https://www.cpcwiki.eu/index.php/B-ASIC

Logon Bashing

L'auteur aime les histoires, les petits conflits... alors du bashing...😛

Je n'ai pas ce souvenir et donc pas la même appréciation des choses. Je n'ai jamais prêté attention aux petites blagues d'adolescents, qui étaient bien moins méchantes ou nombreuses que l'auteur le raconte.

Quel intérêt y a t il à exposer l'attitude immature de quelques personnes dont certaines sont aujourd'hui des adultes encore actifs dans la communauté CPC ?

Raconter que j'étais "très souvent pris à parti" donne une perception éloignée de la réalité. Toute tentative de justification du "Longshot Bashing" dans les démos de l'auteur n'est sans doute pas une coïncidence fortuite....

L'auteur évoque les demomakers AST, KOD et le "groupe" Logogryfikks au sein d'un même chapitre appelé "Les pompeurs du futur" :

(...)

Puisque ça ne sert à rien d'en parler, pourquoi l'avoir fait juste avant puisque "peu de CPCistes se souviennent aujourd'hui de l'existence de ce groupe".

L'Histoire (avec un grand H) de la scène démo CPC ne se serait sans doute jamais remise de l'absence d'évocation de ces petites attaques d'adolescents immatures...🙄

Pourtant l'auteur a fait un second paragraphe complet tout aussi long avec des spéculations pour essayer quand même d'identifier ces adolescents immatures. Je vous fais grâce de ses conclusions. Gala, c'est plus fort que Toi!

L'auteur a fouillé pour trouver un autre exemple de "logon bashing" dans une démo du groupe Paradox:

C'était un poisson d'avril....

Il y a un gros poisson violet rigolo au dessus du texte :

L'auteur a-t-il consulté les membres de Paradox pour que leurs propos d'adolescents soient ainsi extraits et utilisés pour servir sa démonstration ?

Il oublie de préciser que Tronic s'était excusé juste après dans la démo Paradise de son précédent propos.

Conflits intra-scène

Tant qu'à parler de "Logon Bashing", autant transformer tout ça en guerre ouverte entre "adultes"....

Difficile de ne pas voir dans ce paragraphe une nouvelle forme de justification aux propres attaques de l'auteur.

L'auteur reporte en page 145 des potins sur des disputes d'égo entre quelques personnes, qui pourtant avaient l'air de se réconcilier au gré des meetings, et enfonce une porte ouverte en racontant que tout le monde ne peut pas être ami.

Au passage, il se sert de nouveau de moi, et ment de nouveau à ses lecteurs en racontant pour la énième foi que j'étais en conflit avec Fefesse, tout en racontant que les conflits, c'est fécond ! Certainement pas !

Mais ça peut servir quand on écrit un bouquin à charge....

Déluge de ragots

Certains pensent que Memory Fool n'est pas Paris-Match...

En réalité, c'est pire!

Au delà du copinage et de la complaisance du "relecteur" envers "l'auteur", il est intéressant de noter comment ce dernier sélectionne ses cibles.

Dans la dernière période 1994-1997 il utilise des circonvolutions lyriques et enchantées pour certains amis, et une exposition des erreurs de jeunesse pour d'autres, comme il le fait pour Mage en page 151 par exemple.

En page 154, il passe en mode combo sur pratiquement une page complète :

(...) je passe 2 chapitres de ragots (...)

L'auteur n'apprécierait sans doute pas qu'on lui rappelle ses propres errements, mais il a l'air de prendre beaucoup de plaisir à ironiser sur ceux des autres.

Je clos ce dernier opus sur les ragots, qui démontre assez bien comment une soupe de potins, de légendes, de mythes, de dérapages hors contextes et de rhétorique alambiquée permet de raconter à peu près n'importe quoi sur tout.

Je suis loin d'en avoir fait le tour, surtout sur les périodes que je n'ai pas vécues, mais il est certain que cet ouvrage n'a d'historique que le nom.

Il devrait plutôt s'appeler "Les histoires de la demoscène" et c'est malheureusement une des choses qui le rend imbuvable et hermétique pour de nombreuses personnes.

Mes prochains billets vont évoquer les erreurs qui émaillent l'ouvrage, et sur ce sujet, l'auteur n'est pas du tout en reste non plus...

Longshot / Logon System

🇬🇧 English version

Cet article, dans la continuité du précédent, fait l'étude de "Memory Full", un livre qui prétend décrire l'histoire de la demoscene CPC.

Si certains pensaient qu'il n'y avait ni romance, potins ou ragots diffamatoires dans l'ouvrage, je leur conseille de lire ce billet...

La plupart des appréciations sont basées sur des histoires non vérifiées, souvent décontextualisées, et n'avaient pas du tout leur place dans un tel ouvrage car elles n'apportent rien.

Si vous avez lu mes premiers billets, vous devez désormais un peu mieux comprendre pourquoi l'auteur a jugé bon d'en parler à longueur de temps...
Il adore ça!

Oedipe Overflowesque ?

L'auteur devrait vraiment éviter de mélanger philosophie et démo...

Après le "combat de titans" entre Longshot et Fefesse, nous allons voir comment il narre le meurtre (symbolique) de Longshot par Overflow qui voulait prendre sa place au Panthéon des anciens "Dieux" :

Le titre du chapitre annonce la couleur... Je sens que je vais souffrir ! 😬

L'auteur du roman évoque ici la date de diffusion de The Demo.

La partie Phoenix était, à l'instar de quelques autres partie de cette démo, déjà pratiquement achevée en décembre 1989.

Plusieurs d'entre elles avaient déjà été montrées durant le premier Euromeeting officiel en mars 1990, puis durant l'Amstrad Expo en novembre 1990. Son annonce par le magazine Amstrad 100% en décembre 1990 (N° 32) a très considérablement augmenté la pression pour sa sortie.

Overflow, en janvier 1991, ne travaillait pas encore sur la future S&KOH mais sur une autre démo... 😇

Ah bon ? 😮 .... Voyons voir d'où peut provenir ce méchant ragot...

On peut supposer que ce ragot a pris naissance les 26/27 octobre 1991 à l'issue d'un meeting qui a eu lieu à Lyon et avait regroupé une vingtaine de jeunes.

A l'époque, Overflow étudiait dans cette ville et le meeting avait lieu à moins d'un kilomètre de sa chambre universitaire.

J'ai reçu l'invitation à ce meeting le 18 octobre 1991, bien trop tard pour prévoir quoi que ce soit. "Titi the king", l'auteur du potin, était peut-être sans le savoir le père spirituel de l'auteur ?

Les propos de "Titi the king" restent ceux d'un adolescent de l'époque : comme il l'indique en fin de fanzine, il était désappointé de ne pas voir toute l'équipe Logon débarquer au pied levé à Lyon.

Il en avait déduit que nous étions fâché avec Overflow, qui était le seul présent, et que nous avions snobé leur meeting. Overflow, interviewé dans le même fanzine, avait cependant démenti ce potin :

Dix ans après, lorsque Tony a interviewé Overflow dans le fanzine Quasar Disk 3 (nov 2001) il l'a questionné sur son parcours.

Mais il l'a surtout cuisiné pour tenter de savoir pourquoi il avait arrêté le CPC en ressortant ce vieux ragot.

Il a donc ponctué son interview par des "C'est là qu'intervient la discorde avec les Longon ?" , "Et que décides tu ?" (release S&KOH), "C'est ainsi que tu fus banni des logon car tu n'avais pas respecté la règle du groupe...", "C'est le groupe qui t'a largué , à cause de tout ça ?", "Et alors tu as quitté le groupe ?" Une vraie interview Memory Full !

L'interview était donc assez orientée, posant le potin en affirmation :

Overflow s'est peut-être cru obligé de donner un os à ronger à Tony. Il indique clairement qu'il était un adolescent mal dans sa peau à l'époque (un "Neird").

Je le répète de nouveau, mais la démo c'est du "fun" avant tout et pas une guerre pour savoir qui est le premier à faire une chose. Je donnais mon avis même si ce n'était pas toujours ce que certains voulaient entendre, mais je n'aurais jamais imposé quoi que ce soit à quiconque. Et je n'avais donc en conséquence aucune raison de me fâcher avec Overflow.

L'enquête de l'auteur se poursuit sur le "meurtre du père" (déjà agonisant) :

Je suis parfaitement informé de ce qui s'est produit entre juillet 1992 et le 5 avril 1993, et quelles sont les raisons qui ont amené Overflow à arrêter le CPC mais ce serait parler de sujets qui ne concernent personne, surtout pour alimenter une curiosité que je juge assez malsaine, comme vous vous en doutez en me lisant.

Nous avions vu que l'auteur assimile le groupe Logon à une institution, et va même jusqu'à le personnaliser pour le décrire. Ce genre de métaphore, via les propos de "Overflow Ado", est bien pratique pour affirmer que le groupe n'existait plus ou ne faisait plus rien du tout.

Et donc, sans même savoir ce que nous faisions, l'auteur du roman enterre le groupe, et plus encore... Vous le sentez arriver, le coup de poignard ?

Fallait l'oser celle là ! Meurtre, génération, prodige montant.... !

Je me demande si l'auteur est de la 4ème ou de la 27ème génération de demomakers après Shap ? 🙄

35 ans après, l'auteur a réussi à faire mieux que la "Logon démo 3" (1988) avec une démo appelée "Osc 3" (2023) en y intégrant un remix de la musique Short Circuit que j'avais utilisé à l'époque... (Sans doute un nouvel "hommage").

Mais du coup ? Suis-je devenu son "père spirituel" ? 😬 Suis je en danger ? 😱

A moins que ce soit Overflow qui soit symboliquement assassiné dans le prochain volume autobiographique de cette tragédie grecque...😅

Après tout, ce tome 1 était sensé m'enterrer...

Plus sérieusement, Overflow et moi avions des rapports épistolaires fréquents (et il faut voir la longueur des courriers d'un Overflow ado !).

Est ce que j'étais pour autant inactif ? Non.

Est ce que j'avais envie que quelqu'un fasse mieux ? Oui bien sûr !

Est-ce que je considère que ces techniques sont complexes ? Non, il n'y a que l'auteur qui en fait un tel fromage sur 180 pages:

J'ai finalement écrit "Longshot Demo", "Revolog", "Amazing" et "Phenix part" dans une période de 6 mois environ.

Pour me dévaloriser, l'auteur est souvent revenu sur une phrase que j'aurais prononcée lors d'un échange avec Overflow concernant la technique de rupture verticale, et il ne pouvait donc pas faire l'impasse pour ses lecteurs :

Ce qui est cocasse (dixit), c'est que l'auteur soit resté coincé des années sur ce potin et n'imagine pas que j'ai pu suivre de près les progrès de Overflow ou de Duncan. Et surtout que je n'ai pas fait mes propres essais ? 🙄

Qu'allait devenir la démo S&KOH de Overflow, maintenant qu'elle avait été montrée durant le meeting Lyonnais ?

Overflow avait fait 3 propositions pour la sortie de S&KOH et m'avait demandé mon avis. Il était parfaitement libre de choisir l'option qui lui convenait le mieux.

C'est un bullshit d'affirmer que sa démo est sortie "contre mon avis".

L'auteur essaie de démontrer que je menais le groupe "d'une main de fer" (voir page 102) et me définit ainsi comme un autocrate.

Il évoque la sortie d'une intro dont Overflow ne savait en réalité pas quoi faire :

Il est étonnant que l'auteur manifeste une forme de mépris pour le fanzine de Madram, qualifié assez péjorativement de "premier fanzine venu"...

Oui ! Pourquoi ?? 🐽

D'ailleurs, pourquoi cette intro est-elle signée Logon System ?

L'auteur est en roue libre dans son délire oedipien : La rivalité de octobre 1991 va maintenant se muer en "mésentente" jusqu'au départ de Overflow en avril 1993 :

Overflow a évoqué sa période Neird dans quelques interviews dans les années 2000. Comme Gozeur ou bien d'autres jeunes de l'époque, il regrettait certains propos ou attitudes, qu'ils considéraient comme des erreurs de jeunesse.

Ce genre de choses qu'on peut tous avoir dites ou faites.

Par simple respect (surtout lorsque les intéressés n'ont pas été consultés), ces propos méritaient de rester où ils sont, plutôt que d'être instrumentalisés de la sorte.

J'ai su éluder ce type de propos à l'époque en tant qu'adulte.

Aussi je trouve médiocre ce procédé qui consiste à ponctionner des extraits de ces textes en connaissance de cause pour dresser ce type de récit, qui plus est lorsque certaines de ces personnes sont encore actives ou passionnées par le CPC.

L'auteur a déjà démontré qu'il n'appréciait guère de goûter à sa propre "médecine". Un peu comme un Paparazzi qui ne voudrait pas être pris en photo à son insu pour venir grossir le populisme d'un tabloïde.

Contrairement à ce qui est affirmé, nous sommes restés en bons termes avec Overflow jusqu'au moment de son départ, lorsqu'il a été temps que les routes se séparent pour avancer dans la vie. Le temps peut émousser les mémoires, mais les courriers ne mentent pas.

Les propos de l'auteur sont diffamatoires en racontant que j'avais des différends avec plusieurs personnes, sans doute pour mieux justifier sa propre attitude avec moi.

Ca ne devait pas être une si grosse mésentente puisque j'ai revu Overflow avec grand plaisir quelques années plus tard, une fois qu'il avait avancé dans la vie. Et c'est avec grand plaisir que je suis heureux de voir que Overflow signe encore ses productions avec Logon System en 2024.

Longshot, ce despote !

L'auteur, après m'avoir inventé des différends avec plusieurs personnes, après m'avoir accusé de voler le mérite de NWC pour rester le "Dieu du CRTC" ou le "premier demomaker de l'histoire", me fait passer pour une personne intransigeante, autoritaire, jalouse et mesquine.

A cette fin, il va de nouveau s'appesantir lourdement sur la diffusion de la démo S&KOH avec une histoire abracadabrantesque:

Sans avancer la moindre preuve de ce qu'il avance, l'auteur m'accuse de nouveau d'être en conflit avec Overflow et invente de toutes pièces une histoire délirante ou j'aurais fait pression sur Zebigboss parce que Overflow aurait refusé de m'obéir....😮

J'ai eu beau torturer Zebigboss en lui montrant des démos de Fred en boucle ou en lui faisant respirer les chaussettes de Pict, je n'ai pas réussi à le faire plier.

Selon l'auteur, mon objectif aurait été d'empêcher Overflow de sortir sa démo S&KOH pour on ne sait quelle raison obscure. 🤪

Il s'agit ici d'une accusation diffamatoire :

Il est déjà anormal que ce roman contienne en masse ce genre de ragots.

Et une fois de plus, l'auteur n'a pas cherché à vérifier ses sources, notamment en contactant Zebigboss pour vérifier la véracité de cette histoire ! (quand à me contacter, il était bien trop haut perché).

Si l'auteur semble ne pas cracher sur tout ce que j'ai pu faire "techniquement à mon 'époque'", il est clair qu'il essaie de me faire passer pour un sale type de manière assez sournoise et hypocrite.

Et je ne suis pas le seul...

Logon, ces malpolis !

Certains membres de Logon auraient été malpolis...

Encore un ragot colporté en roue libre comme une vérité sans que les accusations soient étayées et sans qu'on sache qui sont ces "membres" de Logon System qui auraient été si grossiers.

L'auteur a pourtant interviewé Antoine en mai 2018 sur son portail et aurait pu demander des précisions sur l'origine de ces ragots ou poser la question aux intéressés chez Logon.

On constate toutefois que Face Hugger ne rentre pas dans le jeu de cette question piège. L'intervieweur va alors se payer le luxe de répondre à sa place pendant 6 lignes 🤪.

L'auteur semble ne pas remarquer que les autres questions sont du même tonneau:

Il n'y avait aucune animosité entre les membres de Logon System et de Face Hugger et ce depuis le jour ou sa démo est sortie.

Je lui avais confirmé par courrier et en direct (puisque je l'ai rencontré en Allemagne en 1993) qu'il avait parfaitement raison de trouver les scrollings hardware ennuyeux.

Je pensais le plus grand bien de lui, comme je l'indiquais à Made durant une interview pour Disc Full 9.

Si on prend le temps de lire les réponses de Face Hugger , on remarque qu'il a intelligemment répondu aux autres questions et notamment celle visant Elmsoft (question 8 de "l'interview" prise en référence).

Si vous pensez que j'ai fait le tour de tous les ragots infamants de l'ouvrage, attendez de voir le prochain épisode...

Longshot / Logon System

🇬🇧 English version

Cet article, dans la continuité du précédent, fait l'étude de "Memory Full", un livre qui prétend décrire l'histoire de la demoscene CPC.

Si certains pensaient qu'il n'y avait ni potins ou ragots diffamatoires dans cet ouvrage, je leur conseille de lire ce billet !

La plupart des appréciations posées dans l'ouvrage sont basées sur des histoires non vérifiées, souvent décontextualisées, et n'avaient pas du tout leur place dans un tel ouvrage car elles n'apportent rien.

Si vous avez lu mes premiers billets, vous devez désormais un peu mieux comprendre pourquoi l'auteur a jugé bon d'en parler à longueur de temps...
Il adore ça!

Un heureux hasard ?

L'auteur indique que les démos ne circulaient pas forcément très vite à l'époque. Même si il prétend en avoir conscience, il a tendance à oublier cette réalité assez souvent, notamment lorsqu'il est question de "diffusion" des productions.

Cela dénote un écart générationnel avec un monde qu'il n'a pas vécu et qui ne connaissait pas l'instantanéité des réseaux internet et les avantages de la téléphonie mobile.

Il s'est par exemple étonné que les démos de 3 personnes ne s'étant jamais rencontrées aient des looks similaires :

Ce questionnement est assez étonnant. Aucune transmission de pensée ici...

Toutes les démos et intros de l'époque, et même encore de nos jours, étaient en général composées d'un logo en haut avec un effet, un dessin et un scrolling en bas, à l'image même des autres plateformes prises comme modèle.

Il faut rappeler ici que la scène démo s'est constituée fin 1989 et s'est consolidée avec les scènes étrangères en 1990. Aucune chance donc que des démos aient pu "arriver" chez un des protagonistes cités en 1988.

Si le sujet des démos sur les autres plateformes vous intéresse, je vous conseille la lecture de mon billet sur une démo Atari ST qui m'a inspiré.

Et sur CPC, "on n'invente pas le demomaking deux fois" parait-il. 🤣

Haro aux codeurs C64

L'auteur fantasme une situation ou j'aurais pu impressionner des programmeurs C64 bossant pour Ubi Soft et qui dénigraient le CPC en 1988 :

Cette remarque est sans doute là pour repréciser une énième fois au lecteur distrait la paternité des techniques, mais elle est hors-sol pour plusieurs raisons :

Lancer le jeu Genocide ou Trailblazer devant des codeurs sur C64 les aurait bien fait rire et montre que l'auteur n'a aucune idée de ce que peut faire un C64 sur le plan technique.

Je dois la première explication sur les barres de couleur à Yves GROLET (Ram, groupe CFR), qui a commencé sa "carrière" comme un brillant programmeur sur C64 et Amiga. Hello Yves si tu me lis.

Sans avoir une connaissance pointue de la machine, personne ne peut "détecter" qu'une routine est faite à l'aide d'un truc "hardware" ou "software", surtout sans avoir essayé de programmer les deux. Il est facile avec 40 ans de recul de comprendre les limites de performance d'une machine, mais à l'époque, on pouvait avoir deux jeux en 3D isométrique avec des performances bien différentes.

Concernant Trailblazer, une personne qui n'a jamais programmé un raster n'a pas le bagage technique pour faire d'emblée une telle observation. Et c'est la même chose pour le scrolling hardware de Genocide à 25Hz, d'autant que les joueurs retenaient surtout que les sprites limités à 3 couleurs en mode 0 étaient assez moches (à cause d'une technique dite de Dual Playfield, mais c'est un autre sujet).

Enfin, les plus gros crackers n'avaient pas la possibilité de posséder tous les jeux existants sur la machine et trimbaler des centaines de disquettes...

N'ayant pas de machine temporelle pour venir consulter CPC-POWER je ne connaissais pas le jeu Genocide. Fred Crazy (Logon System) me l'a fait découvrir en 1990.

On peut regretter que la scène démo CPC ait démarré bien trop tardivement par rapport à celle du C64. Avec davantage de talents motivés, il y aurait certainement eu plus de belles productions scénarisées.

Jeter des kilos de tomates sur les anciens demomakers qui ont eu l'affront de repointer leur museau n'était certainement pas la meilleure méthode.

Naissance d'un DIEU !

Nous allons voir comment en l'absence de contexte, on peut vite se retrouver caricaturé dans la Chapelle Sixtine...

Tous les codeurs du château de Ubi Soft avaient suivi l'annonce officielle télévisée retransmise par satellite dans 64 pays, après que le nom du groupe ait été enregistré au journal officiel !

Une fois pour toute : Logon existe officiellement en 1988.

L'auteur va cependant "imaginer" une scène française inexistante fin 1988:

A une époque "non internet", les jeux et à plus forte raison les démos ne circulaient pas très vite. Le phénomène était amplifié pour les "codeurs" situés en province ou cloitrés dans un château, par exemple.

Cette inertie est sans cesse occultée dans l'ouvrage.

Mes premières démos ont assez peu circulé. Certains de mes contacts ont trouvé mes démos intéressantes, mais pour beaucoup, les démos, ce n'était pas leur "truc", comme de nombreuses personnes de nos jours dans l'univers CPC.

Après ma période "Ubi Soft" je n'avais plus d'intérêt pour "cracker" des jeux. Mes démos ont circulé localement (par exemple chez Nouzotre) mais il n'existait aucune scène démo.

Je me suis rapidement retrouvé coincé début 1989 sur une base militaire pour réaliser un long service militaire de 12 mois.

La suite de "l'histoire", contée par l'auteur du roman, est un énorme feu d'artifice de fake news inventées sans aucune preuve.

Si vous avez suivi mes articles, voici quelques dates précises en rapport avec la chronologie de la scène démo :

Je connaissais donc 4 ou 5 personnes en arrivant à l'Amstrad Expo 89, et pratiquement personne ne connaissait mes démos.

C'était aussi le cas pour BCAV (Fefesse) et Malibu Crackers car il n'existait pas encore de "demoscene française".

Comme je l'ai déjà évoqué, ce réseau s'est constitué en partie grâce à mes démos et au magazine Amstrad 100% qui réclamait ce type de créations, afin de voir enfin une scène démo émerger sur CPC.

C'est l'envoi conjoint à la rédaction de Amstrad 100% des productions de plusieurs codeurs vers juillet 1989 qui a permis ce rapprochement. Cela a permis quelques rencontres lors de l'Amstrad Expo 1989 sur le stand du journal.

J'étais une des rares personnes à avoir mis ses coordonnées dans ses productions. Les groupes de "Crackers" ne risquaient pas de faire la même chose, et ce n'est pas pour rien qu'ils utilisaient des "pseudos".

On peut toutefois noter que Fefesse, alors "BCAV", avait donné son tél dans "Bo Demo" sous format hexa. Rappelons ici pour les plus jeunes qu'il s'agissait de téléphones "fixes" non transportables. 😂

Il fallait donc pouvoir se contacter avant de pouvoir même se donner rendez-vous dans une manifestation étalée sur plusieurs jours dans le vaste espace du Parc des Expositions de la porte de Versailles, dans le sud de la capitale.

C'est Amstrad 100% qui a initié cette démocratisation de la démo sur CPC. Et c'est via mes démos que la plupart des personnes intéressées ont constitué un réseau. J'étais une des rares personnes en France à s'exprimer en anglais. Et ce n'est donc pas un hasard si j'ai hébergé quelques Allemands chez moi à Paris dès début 1990.

Contrairement à ce que l'auteur raconte, les meetings en France ne sont pas nés de l'Amstrad Expo et certainement pas de l'édition 1989.

Si le Cebit était un moyen de se rencontrer pour la scène allemande, ce n'était pas pour autant un "meeting" puisqu'il n'y avait pas d'accès "libre" aux machines en exposition.

Même sans tenir compte du cloisonnement et du décalage chronologique entre les scènes française et allemande, c'est une grossière erreur de faire une analogie avec l'Amstrad Expo 89 pour décréter qu'elle "fut exceptionnelle du point de vue demomaking" car.... la scène démo n'existait pas encore!

Toujours sur sa lancée, l'auteur pense que la "démoscène" allemande pouvait profiter du Cebit pour découvrir les "nouveautés de ce qui se faisait" sur les autres plateformes :

Si c'est de démos dont il est question, c'est un fantasme. C'est un peu comme si on entrait dans une FNAC géante ou les exposants, éditeurs et constructeurs, laisseraient des bandes d'adolescents manipuler leur matériel en y installant des logiciels hackés ou des démos !

En 1989, l'Amstrad Expo restait le meilleur moyen de découvrir les dernières nouveautés en matière de jeux et de hardware auprès des différents exposants. Des magazines comme Amstrad 100% étaient présents pour gérer leurs annonceurs.

Les téléphones portables n'existant pas, personne ne se baladait avec son nom (ou son pseudo) collé sur le front, au milieu d'une foule dense de milliers de personnes. Il fallait qu'un exposant soit intéressé par les démos, et en l'occurence, il s'agissait du magazine Amstrad 100%.

Ce sont surtout mes 2 dernières démos ("Longshot" et "Revolog") qui ont commencé à circuler à partir de cette date et qui ont permis à de plus en plus de monde de prendre contact avec moi.

En 1990 j'avais déjà échangé 150 courriers avec pratiquement tous les acteurs de la scène, y compris à l'étranger, et ce nombre avait doublé en 1991.

Raconter que ma première démo "restera longtemps une référence" à partir de "fin 1988" est un pur fantasme, tout comme l'idée qu'il y a eu une continuité dans la diffusion quasi instantanée et régulière de mes premières démos et de celles des autres "acteurs" (dans un réseau français inexistant, rappelons le). 🚀

Mais cet artifice permet à l'auteur de narrer ma présence à l'Amstrad Expo 89 de manière assez...fleurie 💐 :

Du haut de mon piédestal, je me souviens en effet de ces hordes de curieux et de demomakers en liesse à qui je lançais des morceaux de mon débardeur et quelques disquettes signées !

Digit trépignait tellement d'impatience pour rencontrer le Dieu du CRTC qu'il scandait mon pseudo en coeur avec Fred Crazy dans les allées de l'exposition 🤪

"Dieu" merci, cela ne s'est pas passé comme ça 😱

Peut-être que cette qualification montre comment l'auteur considère que le "mérite" doit être révéré :

Je ne suis certes pas entré au panthéon, mais Grim (le relecteur de cet ouvrage) m'a dernièrement qualifié de "splitscreen dummy god" (traduisez "Dieu bidon de la rupture CRTC"). 🤓

Pour l'auteur, la scène démo est un vrai panthéon...

En 1994, lorsque ce panthéon s'écroule, l'auteur du roman écrit :

Nous y voilà.

Une "scène" a donc besoin d'un leader charismatique pour exister.

Un dieu du CPC devrait faire l'affaire... 🤪

Pourquoi pas celui ci à qui certains vouent déjà un culte dans leurs démos:

J'ai essayé de quitter discrètement le panthéon, mais un Titan m'est tombé dessus...

Combat de TITANS !

Avec une conception guerrière de la demoscène, il n'en fallait pas plus pour qu'un potin imaginé par Robby dans Amstrad 100% N°40 (septembre 1991) soit relaté comme une guerre d'égo sur la durée à partir de janvier 1989 !

J'ai contredit ce potin, mais l'auteur a préféré prendre pour "argent comptant" cette information sans la moindre contre vérification.

"En ce début d'année 1989" je n'avais encore jamais vu une seule démo sur CPC, pas plus que Fefesse ou Malibu n'avaient vu les miennes !

Tout le reste relève donc de nouveau du fantasme :

Un truc qui n'a pas pu exister a du faire un "grand effet" ! 😂

Les démos de la première série des "Malibu Demo" ont pratiquement toutes été réalisées en un laps de temps assez court à l'été 89, puis ensuite envoyées groupées à Amstrad 100% (et pas à une scène hypothétique sans acteurs et sans spectateurs).

Sauf erreur de ma part, la date de création de "The Last Demo" n'est pas connue.

Cette opposition "technique/esthétique" est totalement bidon...

On se demande bien aussi qui étaient ces pros et ces antis qui n'étaient pas rares.... L'auteur devrait pouvoir en citer beaucoup !

Ce qu'on a pu trouver, lorsque les démos ont commencé à circuler, c'étaient plutôt des messages adressés aux deux sans que l'un exclue l'autre.

Pour inventer des raisons à une "rivalité inexistante", l'auteur va évoquer les transferts de musique que j'ai réalisé à partir de l'ATARI ST : 😮

En effet, Fabien briguait un poste auprès de "CPC Demoscene Company Illimited" depuis des mois, mais personne ne lui a répondu...

J'avais menacé son patron pour qu'il n'embauche pas Fefesse, et un "semblant de scène" n'existait pas encore à cette époque...

Au delà de l'affirmation sortie du chapeau, transférer une musique ne fait pas de la personne qui le fait un spécialiste de la "programmation musicale".

Ca se saurait !

Il n'y a jamais eu de "guerre plus ou moins ouverte" entre Fefesse et moi.

L'auteur se montre sélectif dans les textes de Yao Demo.

Il utilise une technique dite de "Cherry Picking", qui est un procédé de présentation des faits ou des données qui donnent du crédit à son opinion en passant sous silence les cas qui la contredisent.

Par exemple, dans ses textes, Fefesse s'adresse à moi par mon prénom pour me demander conseil pour ses études en informatique. Cela démontre que nous étions amis. En tenir compte aurait nuit à la "démonstration" de l'auteur.

Pour renforcer sa démonstration, il affirme également que la musique du dernier écran de la Yao Demo provient "de la megademo Cuddly", transféré sur ST par Fefesse. C'est faux.

Il s'agit en réalité de la musique ST Thrust que j'avais transféré pour Revolog. Fefesse m'avait demandé si il pouvait l'utiliser dans sa démo et l'indique d'ailleurs au tout début de sa démo...

Ca sentait la compétition féroce....🤪

Nous avions donc déjà une correspondance nourrie et amicale en 1989.

L'auteur invente trois "raisons" pour justifier cette "guerre de Titans", et on peut mesurer son imagination débordante.