[EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Couvre tous les domaines de l'émulation ou de la virtualisation ainsi que les discussions sur les divers outils associés.

Modérateurs : Papy.G, fneck, Carl

yves
Messages : 464
Inscription : 12 sept. 2007 21:32

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par yves »

je me répète mais "wow, bravo" :)

Et toujours très intéressant en plus

Yves
Dmanu78
Messages : 268
Inscription : 20 juin 2020 14:28
Localisation : Yvelines

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Dmanu78 »

Merci à tous. ça me fait plaisir tous ces compliments.J'espère que le produit final ne vous décevra pas après un tel teasing :)

@Sebiohazard
Désolé, j'ai zappé ton précédent post. Alors oui, c'est dans ma "TODO list". j'ai bien prévu d'implémenter des petites informations visuelles pour des accès disquette par exemple ou lors de la lecture des fichiers cassettes. :wink:

@Zebulon
J'espère pouvoir le mettre à votre disposition d'ici avril-mai je pense. Il est encore trop brut de décoffrage. :)

Par ailleurs, puisque la question va se poser plus ou moins rapidement, j'aurais une question d'ordre légale : peut-on proposer un émulateur CPC avec les ROM d'origine incluses ? Il doit y avoir un copyright, non ?
Sur les émulateurs d'ATARI ST", machine que j'apprécie beaucoup également, je sais qu'il faut chercher les ROM soit même. En est-il de même sur CPC ? J'ai un doute suite à la lecture de plusieurs articles sur le sujet.
Lone
Messages : 16
Inscription : 26 nov. 2020 09:53

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Lone »

Hello, toujours un plaisir à lire !

Je peux répondre concernant les ROM : elles peuvent être incluse désormais légalement avec les émulateurs.
Je ne retrouve pas mes sources, mais je l'avais vu (sur le cpc-wiki peut être ?). Si je retrouve, je complète !
Dmanu78
Messages : 268
Inscription : 20 juin 2020 14:28
Localisation : Yvelines

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Dmanu78 »

Hello Lone.
Super info. Je vais donc pouvoir mettre les ROM « en dure » dans l’émulateur. Ce sera bien plus simple à gérer. J’avais bien vu un article sur le sujet à une époque mais je préfère avoir plusieurs avis...
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par hlide »

Ouais attention, certains personnalisent les ROM. Et puis il y a les langues...
Zebulon
Messages : 2788
Inscription : 02 nov. 2020 14:03

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Zebulon »

Concernant la diffusion des roms, même s'il est indéniable qu'elles sont largement diffusées ci et là et présentes avec la quasi-totalité des émulateurs dispos, difficile de donner des conseils. Les deux propriétaires sont Amstrad et Locomotive Software (apparemment racheté depuis) peut-être est il possible d'obtenir l'aimable autorisation écrite pour être couvert.

Sinon je me posais une question sur le choix qui sera retenu en matière de mapping des touches entre l'hôte (PC) et la machine émulée. Il y a deux écoles en gros. Le mapping hardware qui privilégie la position des touches sur le clavier du PC pour coller au plus près de celle du CPC faisant fi des caractères indiqués sur les touches du PC (donc nécessité d'apposer des stickers ou de mémoriser le clavier). Le mapping logiciel qui privilégie les caractères générés par les touches (ou combinaisons de touches) pour générer ces mêmes caractères dans le CPC au détriment de l'ergonomie (car les touches spéciales CTRL, COPY et même SHIFT sont exilées).

S'ajoute à cela la complexité du fait qu'un utilisateur voudrait utiliser le CPC dans différentes langues.

Aujourd'hui aucune des propositions faites par les émulateurs existants ne me convient totalement selon l'usage (jeux ou programmation).

J'avais prévu de "stickeriser" un clavier QWERTY pour programmer avec en mode mapping hardware mais les stickers découpés (car certaines associations de symboles ne sont pas les mêmes que sur les claviers actuels) c'est très bof.

C'est un sujet qui paraît bien secondaire par rapport à l'émulation elle même mais pourtant si on veut utiliser l'émulateur autrement qu'avec un joystick ou un gamepad ça devient primordial. :D
Lone
Messages : 16
Inscription : 26 nov. 2020 09:53

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Lone »

J'ai retrouvé une source :
https://www.grimware.org/doku.php/docum ... repository
http://www.winape.net/help/general.html

Je n'ai pas la source originale, pour peu qu'elle existe....
Zebulon
Messages : 2788
Inscription : 02 nov. 2020 14:03

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Zebulon »

C'est bizarre je n'arrive à ouvrir aucun des fichiers ZIP disponibles sur le site grimware'... C'est quoi le truc ?
Dmanu78
Messages : 268
Inscription : 20 juin 2020 14:28
Localisation : Yvelines

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Dmanu78 »

Ah oui, je confirme je n'arrive pas à lire les ROMs dézippées. J'utilise 7-zip pour info. Etrange.

Je viens de regarder quelques émulateurs CPC et les ROMs y sont bien intégrées par défaut. Si j'ai bien compris, si on utilise les images des ROMs originales non modifiées, on peut les distribuer librement avec l'émulateur.

@zebulon
Le mapping clavier est en effet plus compliqué qu'il n'y parait sur CPC où la ROM lit tous les 1/50em de seconde l'état de 10 "lignes" composées de 8 touches du clavier CPC (soit 80 touches analysées au total), avec 3 niveaux de "buffering" pour gérer les répétitions notamment. C'est très élaboré je trouve.

Sur mon émulateur, ayant une ROM Anglaise par défaut (clavier QWERTY donc) je suis parti par défaut sur un mapping logiciel car j'en avais assez de chercher les correspondances des touches entre mon clavier PC Azerty et celle du CPC émulé.

Ma routine de mapping est finalement assez complexe, j'y ai passé un peu de temps de réflexion mais elle me donne satisfaction pour mon usage personnel. J'écris dans mon émulateur CPC aussi naturellement que je le ferai sur un vrai CPC sans m'occuper des correspondances de touche. Les touches SHIFT/CTRL du PC ont les mêmes actions que sur CPC. J'arrive à afficher correctement tous les caractères du CPC à partir du clavier PC, y compris en combinaison avec la touche CRTL, et même à utiliser le mode COPY du CPC sans problème (SHIFT + Fleche + COPY (remplacé par la touche Ins chez moi).

Il faudra que tu testes et tu me diras ton avis car je suis peut être passé à côté d'un truc.

Le seul truc que je n'ai pas implémenté pour l'instant est la gestion des "touches" des joyticks. Il faut utiliser une API Windows spécifique. J'essaierai de l'implémenter avant de diffuser l"émulateur.
Dmanu78
Messages : 268
Inscription : 20 juin 2020 14:28
Localisation : Yvelines

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Dmanu78 »

Je continue dans ma lancée. Je vous rassure, j'arrive presque à la fin...

Au moment où j'écris ces lignes on est grosso-modo fin 2020. Le socle technique de l'émulateur est désormais solide, avec une émulation du Z80 quasi-parfaite, une émulation vidéo fonctionnelle (mais encore partielle on le verra plus loin), une émulation sonore satisfaisante et une émulation du contrôleur de disque partielle mais suffisante pour lire les fichiers.

Mais avant cela, j'ai oublié un aspect essentiel du CPC 464, l'émulation du lecteur de cassette bien entendu.
Sur un CPC464, c'est le média de référence, avant même le lecteur de disquette.
Ainsi, je change un peu mes plans initiaux et décide quand même de terminer ce petit chantier avant d'aller plus loin.

Comme indiqué plus avant, l'émulateur sait gérer les formats de fichier .WAV et .CDT; Il me reste maintenant à réussir à les faire lire par les routines natives présentes dans la ROM du CPC, comme pour un vrai CPC tout simplement.

La lecture du flux de données sonores provenant du lecteur de cassette (ou du fichier WAV dans le cas de l'émulateur) est entièrement gérée et pilotée en ROM par le Z80 via une interrogation en boucle du bit 7 du port B du PPI 8255 (1= PULSE HAUT / 0 = PULSE BAS ou inversement, le CPC gère indistinctement les 2 cas sans problème). Et c'est tout. Tout l'art du décodage du flux de données provient d'une maitrise parfaite du timing de lecture de ce bit. C'est en effet le registre "R" du Z80 qui sert à mesurer précisément ce timing, d'où l’intérêt d'avoir une émulation fiable du Z80.

Je me répète mais la routine de lecture cassette en ROM est un trésor d'ingéniosité et d'optimisation. Pour l'avoir analyser partiellement, tout a été fait pour fiabiliser la lecture en un minimum d'instructions. Je pense que le cœur de la routine de lecture prend moins de 100 octets. Impressionnant.

Dans le cadre de l'écriture de la routine simulant le lecteur de cassette et donc l'envoi du PULSE HAUT et BAS sur le bit 7 du port B du PPI, la réelle difficulté a été de synchroniser la vitesse de lecture du fichier WAV (44 khz en général) au sein d'un émulateur fonctionnant à 4 Mhz afin d'envoyer les impulsions à la bonne fréquence pour que la routine en ROM ne perde pas sa synchro lors de sa lecture en boucle.

Il y a une deuxième difficulté que j'ai eu du mal à comprendre au départ : régulièrement, le CPC coupe de lui-même le moteur du lecteur de cassette afin de se donner le temps de "décoder" le flux de données et de vérifier notamment le CRC (avec l'affichage du fameux message "READ ERROR B" en cas de désaccord). Cette simple particularité m'a obligé à revoir complètement l'écriture de la routine afin de pouvoir dans ce cas "couper" la lecture du flux de données, et reprendre la lecture quand le moteur est réactivé.
Enfin, dernier petit détail "nice", la lecture d'une cassette s'accompagne sur un vrai CPC produit un son caractéristique que j'ai cherché à reproduire. Cela me permet d'être sur que la lecture est en cours...

Après quelques jours de coding, l'émulation commence à prendre forme mais n'est pas encore parfaite...

Image
Et oui, le fameux "read Error b". En fait, je lisais le flux sonore en continu sans intégrer la coupure du moteur du lecteur.

Une fois corrigé, ça commence à beaucoup mieux fonctionner. Je lance alors le chargement des premiers jeux commerciaux, pour voir ...

Image
Ok. Mercenary semble se charger correctement. :)

Image
YES ! Enfin, le jeux se lance sans aucune erreur :) Je vais pouvoir commencer à rejouer à mes antiques jeux. :D

Image
Autre jeux. Ici SORCERY en cours de chargement.

Image
Et une fois chargée. Tout va bien :)

Au final, "the job is done". La routine de lecture des fichiers "TAPE" semble désormais fonctionner correctement. Une bonne chose de faite sur ma TODO liste. Petit à petit l'émulateur gagne en fonctionnalité et commence à se comporter dans un vrai CPC..

Vous l'aurez certainement noté, pour l'instant, je me focalise sur la lecture uniquement. Je n'ai pas encore écrit les routines d'écritures, que ce soit sur cassette ou disquette. Ce sera fait dans un deuxième temps. C'est moins primordial pour la poursuite des tests.

Voilà. A ce stade du développement arrive désormais l'étape où je vais commencer à titiller le CRTC à travers l'exécution des plus exigeants des programmes : les démos.
Je dirais que l'on commence à rentrer dans les réglages "fin" de l'émulateur dans lequel les timings de chaque instruction, les cycles /WAIT, le comportement du CRTC prennent un part prédominante dans le rendu final...On rentre dans une étape exigeante, celle où l'on repousse l'émulateur dans ces derniers retranchements...et qui permet au final de juger effectivement de la précision globale d'une émulation.

J'en suis actuellement à cette étape, je ne sais pas quand elle se terminera mais rien ne m'empêche de vous montrer l'état d'avancement de mes progrès en la matière...
Ce sera donc pour un prochain post. Wait & See :)
Zebulon
Messages : 2788
Inscription : 02 nov. 2020 14:03

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Zebulon »

Belle victoire que cette routine de lecture de K7. :D

Deux choses me viennent à l'esprit:
- tout d'abord le prodige de recréer ce mix entre analogique et numérique et le faire dans un programme qui lui est 100% numérique,
- ensuite effectivement l'ingéniosité des concepteurs d'origine pour gérer cette lecture/écriture (même si aujourd'hui on crierait au scandale, quoi le noble CPU 100% dédié à cette tâche subalterne d'entrée/sortie :P ) et surtout la créativité et non moins ingéniosité de ceux qui ont ensuite supplanté cette routine et créé les loaders les plus fous que ce soit pour protéger les logiciels ou optimiser les temps de chargement. :wink:

Pour la gestion du clavier je crois que c'est le meilleur mix.
Dmanu78
Messages : 268
Inscription : 20 juin 2020 14:28
Localisation : Yvelines

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Dmanu78 »

Suite et désormais (presque) fin de la genèse d'un émulateur Amstrad CPC qui a débuté, je viens de m'en apercevoir, il y a juste 3 ans maintenant...

Image
Début de l'aventure en février 2018 avec ses premiers mots sur un bloc note vierge... Que de chemin parcouru depuis !

Trois ans pris sur mon temps libre pour bâtir un émulateur à partir de rien, avec juste l'envie de faire revivre un CPC sur un PC en reproduisant de toute pièce le fonctionnement intime de ses organes internes..Avec un crayon papier, un bloc note, quelques ouvrages, de nombreuses heures de lecture, j'ai patiemment compilé les informations et commencé les développements.

Je vous ai décrit les différentes étapes fastidieuses de la construction de cet émulateur au fur et à mesure de mon cheminement intellectuel dans ce projet, avec de nombreux allers-retours, de tâtonnements. Ce fût d'autant plus fastidieux que je n'ai pas souhaité m'inspirer des nombreux codes sources existants qui auraient pu me faire gagner énormément de temps. Non, je voulais tout redécouvrir, créer l'émulateur à ma façon, sur une voie encore toute vierge. Tout a donc été patiemment crée de zéro après de longues heures et journées de recherche, de lecture, de compilations d'informations...avec ce simple objectif de pouvoir faire revivre le CPC de ma jeunesse. Ma madeleine de proust on dirait.. :D

Image
Mes différentes sources de lecture patiemment épluchées, analysées, digérées...et codées

Tout cela pour aboutir après 3 années donc à un émulateur qui commence à reproduire de façon convaincante le comportement d'un vrai CPC..A ce moment du développement, c'est le rêve qui commence à prendre forme et on se dit qu'on commence à toucher du doigt le but qu'on s'est fixé....

Mais la réalité nous rattrape très vite et l'objectif de récréer l'émulateur parfait se heurte rapidement à cette terrible vérité : la diable se cache dans les détails...car c'est dans les détails maintenant, des petits rien, des petits ajustements de code de rien du tout que toute la précision de l'émulation va se révéler...et ça devient tout d'un coup compliqué, très compliqué. Je m'explique...

Jusqu'à présent, je n'ai fait qu'exécuter de longues séries de tests pour vérifier le bon fonctionnement de l'émulateur dans des conditions plus ou moins standards. Des programmes de tests, des petits programmes pas trop exigeants, souvent écrits en Basic ... A ce stade, l'émulateur est prêt à faire tourner 80-90% des programmes disponibles, pour peu que l'on ne soit pas trop exigeant..

Mais par définition, l'émulation doit tendre à reproduire à l'identique le fonctionnement de la machine à émuler dans tous les cas, y compris dans des conditions non standards. Et le degré de précision exigée devient alors extrême, à la microseconde près dans le cas d'un CPC. Et pour tester dans ces conditions extrêmes, rien de tel que de lancer des démos qui vont pousser le CPC dans ses derniers retranchements.
L'optimisation des démos est telle qu'un simple décalage de timing d'une microseconde sur une instruction, voire moins, peut se traduire par des glitchs visuels à l'écran. C'est un test redoutable.

Dans ces situations d’utilisation non standard, le problème principal vient du fait qu’il n’y a plus de documentation officielle. A moins de coder soit même les tests sur un vrai CPC, il faut parcourir des sites de passionnés, des forums pour trouver des bribes d’informations. C’est ce qui me manque le plus sur le CRTC et la Gate Array...une doc complète et exhaustive. A défaut, pour les tests, j’y vais souvent à tâtons en testant un peu au hasard des combinaisons de code. Souvent ça régresse mais parfois on a la bonne surprise de voir que ça passe et quelque fois, que ça corrige le rendu d’un bon paquet de demos d’un coup. Et là on se dit qu’on tient un bout de vérité...

Alors ces derniers temps, je travaille à trouver les bons réglages sur le couple Z80-GateArray-CRTC. L'avantage de travailler en T-States, c'est que je peux jouer sur des réglages de timing de l'ordre du quart de microseconde sur le CPU. Par exemple, je me suis aperçu que mettre un cycle d'attente /WAIT sur le 2em ou 3em cycle T-state de l'instruction OUT du Z80 changeait complètement le rendu final à l'écran sur certaines démos...

Sur CPC, rien n'est simple, et ce travail est complexifié par le fait qu'Amstrad a utilisé plusieurs variantes du CRTC qui ne réagissent pas de la même façon. Et comme les démos ne précisent généralement pas pour quelles versions de CRTC elles ont été développées, le débogage en devient vite compliqué...Ce que l'on croit être un bug de fonctionnement sur un modèle de CRTC est juste...normal. D'où l’intérêt d'avoir toujours un vrai CPC à proximité pour tester le rendu d'une démo. C'est le juge de paix.

Ma méthodologie de tests consiste donc à charger une démo (plutôt simple de préférence), de voir son rendu sur l'émulateur. Si elle ne rend pas bien, je vérifie sur un vrai CPC, et si c'est Ok alors je corrige mon code jusqu'à avoir le rendu escompté et je passe à une autre démo .. et je corrige si besoin et ainsi de suite... sauf que la correction d'une démo peut casser le rendu d'une autre démo...ça m'est arrivé plusieurs fois. Il faut donc sans cesse tester la non-agression sur plusieurs démos afin de vérifier que l'on a rien cassé en modifiant un petit bout de code...quand je vous dis qu'il faut être très patient !

Chaque démo passée avec succès est donc un pas de plus vers le but fixé mais la contrepartie est qu'elle aura souvent nécessité de nombreuses heures/jours de débogage afin de pister et de comprendre l'origine du dysfonctionnement. Et par dysfonctionnement, il faut comprendre un décalage de rendu visuel de parfois d'une microseconde, ou d'un signal VSYNC généré une ligne trop tôt ou trop tard.. C'est fastidieux mais au final, cela permet d'améliorer progressivement la précision de l'émulation. C'est le prix à payer.

Quelques exemples pratiques :
Image
Ce test m'a permis de vérifier le bon timing entre l'instruction OUT du Z80 et le rendu d'affichage via le Gate-Array.

Image
Cette petite démo, plutôt sympa, est exigeante : toute erreur de timing sur les instructions du Z80 se traduit par un défaut visuel. Cette démo m'a permis de corriger 2 bugs de timing sur le Z80...

Image
Cette démo m'a permis de corriger un problème de rendu sur le Gate-Array lorsque le compteur d'interruption est forcé à zéro juste après le VSYNC du CRTC...

Image
J'ai mis longtemps à déboguer cette démo. Là c'est l'émulation du registre R5 du CRTC qui posait problème car la VSYNC s'active juste pendant l'affichage d'une nouvelle FRAME. C'est l'overscan de ce registre R5 qui cale le début de l'image. Un peu tordu je trouve.

Image
Cette démo est très bizarre. Pour bien la gérer, j'ai du mettre une "verrue" dans le code du Gate-Array et je déteste faire cela. Les lignes sombres correspondent à un signal VSYNC envoyé par le CRTC en milieu d'écran. Normalement un signal VSYNC est généré pour déclencher le début d'une nouvelle FRAME à l'écran sauf que là non, l'écran affiche une ligne noire mais continue son balayage comme si de rien n'était...Tout est atypique et ça ne correspond pas à ce que j'ai lu...Je reste dubitatif !
Je continue à penser qu'un bon émulateur doit fonctionner naturellement, sans patch ou verrues particulières dans son code pour simuler tel ou tel comportement atypique. Tout doit être aussi naturel et universel que possible.

Image
Impact de la version du CRTC : CRTC "Version 0" correctement émulé. Tout va bien.

Image
La même démo sur le CRTC version "1" de mon CPC. Le rendu est différent mais correct néanmoins... Cherchez l'erreur ! L'émulateur devra donc simuler les différents comportements des différentes versions du CRTC. Une difficulté supplémentaire.

Image
Et celle là..non rien, c'est juste pour finir sur un visuel sympa.:)

Ce sont des démos qui fonctionnement ..mais de nombreuses autres ne passent pas encore. L'aventure continue donc :)

Voilà j'en ai fini avec cette petite genèse... Mais vous l'aurez compris, l'histoire n'est pas finie et je continuerai à alimenter ce post par petites touches au fur et à mesure que j'avancerai dans mes tests.
J'espère bien vous communiquer bientôt une première béta en primeur ...il n'y a pas de raison qu'il n'y ait que moi qui m'amuse :)

J'espère que cette petite histoire à travers mon expérience personnelle vous aura plu et fait prendre conscience de la difficulté à écrire un émulateur même pour un simple ordinateur 8 bits.
C'est un challenge vraiment passionnant intellectuellement mais je conviens qu'il faut une très grande motivation pour passer son temps libre à développer quelque chose qui au final n’intéressera pas grand monde à par soi, si ce n'est quelques passionnés, mais avec la satisfaction au final d'avoir construit soi même quelque chose dont on peut être fier. Ce n'est finalement pas rien :)

A suivre...
Dernière modification par Dmanu78 le 19 févr. 2021 20:03, modifié 2 fois.
Avatar de l’utilisateur
farvardin
Messages : 436
Inscription : 27 déc. 2014 16:07
Contact :

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par farvardin »

wow, bravo à toi, c'est un travail de longue haleine, mais ça t'a permis d'approcher au plus près des arcanes du CPC !
Markerror
Messages : 2121
Inscription : 31 oct. 2011 19:21
Localisation : Orléans
Contact :

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Markerror »

Bienvenu dans le monde merveilleux de l'émulation CRTC ! C'est clairement un des aspects les plus tordus du CPC. Cinq modèles différents à gérer, c'est quand même assez tordu. Les articles techniques des fanzines "Another world" et Amslive sont de précieux auxiliaires.

Après, il semble y avoir encore pire, avec les MSX :-).
Dmanu78
Messages : 268
Inscription : 20 juin 2020 14:28
Localisation : Yvelines

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Dmanu78 »

Oui tout à fait. Les différents modèles de « CRTC « fonctionnent de manière identique en utilisation standard (en respectant les spécifications des datasheets).
Mais dès lors que les registres du CRTC sont programmés en dehors des clous pour générer des ruptures, des rasters, des overscans, ... des différences subtiles de comportement apparaissent entre les différents modèles. Difficiles de s’y retrouver. Le plus dur est de trouver une documentation unifiée. J’ai réussi à regrouper quelques informations éparses en regardant dans des forums spécialisés, des sites dédiés mais rien encore de vraiment exhaustif. Les informations sont même parfois contradictoires. Je déduis certaines règles de bon ou mauvais fonctionnement de démos...c’est empirique.

ce travail est complexifié par le fait que le rendu vidéo est piloté par le Gate Array et que celui-ci dénature les signaux du CRTC : le GA raccourcit le signal HSYNC du CRTC, déclenche la VBL 2 lignes après l’envoi VSYNC du CRTC (sauf dans certains cas...)...La réinitialisation du compteur d’interruption durant la VBL semble être perturbé par certaines actions, ce qui provoque des décalages de lignes dans l’affichage des lors que les démos s’appuient sur des instructions HALT pour se synchroniser...
Il y a aussi des comportements étranges : par exemple certaines démos utilisent une variation du registre R2 du CRTC pour faire des effets d’ondulation horizontale à l’écran que je ne comprends pas encore puisque ce registre décale normalement l’écran d’un bloc de 2 octets d’un coup (soit de 4 à 16 pixels d’un coup selon le mode affiché). Comment arrive-t-on à générer des effets d’ondulation au pixel près avec cette technique près reste un mystère pour moi ? Je présume que c’est lié à l’écran (avec un écran LCD ça ne semble pas bien fonctionner mais sur un CRT classique l’effet semble bien rendu)...

En tout cas il est très instructif de lancer des démos car chacune d’entre elles est un révélateur du comportement du CRTC en utilisation non standard.
Répondre