Merci @6502man
Il est encore loin d'être terminé mais il se construit petit à petit.
@Markerror. Merci pour le site de Tom&Jerry. C'est très intéressant. En vérité, j'y étais déjà allé précédemment pour la lire l'article sur la gestion mémoire du 6128... J'y ai trouvé de belles démos dont "Tire au flan" (qui ne fonctionne malheureusement pas encore très bien sur mon émulateur...)
Et je comprends mieux d'où vient ton pseudo maintenant
J'en profite pour donner quelques nouvelles. J'ai fait une petite pause ces 2 dernières semaines pour me concentrer sur l'optimisation du code. A force de développer, de corriger ou "patcher" mon code pour coller aux spécificités de telles ou telles démos, je me suis aperçu que celui-ci perdait en lisibilité et devenait une usine à gaz...J'ai donc décidé de faire un peu de revu de code et de réécrire une partie des routines d'affichage ( Gate Array et du CRTC ) pour en simplifier l'écriture et clarifier un peu tout ce monde.
Je reste intimement convaincu qu'il n'y a pas besoin de patcher le code pour faire tourner une démo ou un logiciel spécifique. Si l'émulateur est nativement bien écrit avec des règles bien établies, tout fonctionnera normalement, tout simplement même dans les cas extrêmes. Il faut juste trouver la bonne règle, celle qui est gravée dans ses circuits intégrés de la puce émulée en vérité. Après il y a toujours des exceptions, comme le fait d'avoir une ligne en pointillé avec un "CRTC type 0" lorsque le registre R6 est forcé à 0...ça ne s'invente pas ça.
Les patchs présents dans mon code ont été écrits dans un premier temps pour palier à une absence de règle connue. Comme j'ai des trous de documentation pour le CRTC, ça me sert à comprendre empiriquement comment il doit réagir suite à une modification de tel ou tel registre interne pour faire fonctionner la démo.
Avec du temps et un peu de pratique, et fur et à mesure de l'exécution de différentes démos, le fonctionnement intime du CRTC devient moins mystérieux et je commence progressivement à entrevoir les règles de fonctionnement qui vont naturellement remplacer les patches en place.
Avec ce travail de réécriture, j'ai ainsi pu simplifier la lecture de mon code, supprimer les "verrues" que je trouvais "inélégantes" à la lecture
(oui je suis un peu puriste...)
La grosse difficulté de l'exercice est de veiller à ne pas créer de régressions au gré des modifications apportées. J'ai dû retester une à une toutes mes démos tests afin de vérifier leur bon fonctionnement une fois ce travail de réécriture terminé.
Au final, les démos fonctionnent comme avant mais sous le capot, le code réagit plus naturellement. Cela va me permettre de continuer mes tests sur une base plus saine. Et grâce à ce petit travail d'optimisation, mon émulateur a gagné un peu en performance. Toujours ça de pris.
En parallèle, quelques corrections ont été apportées me permettant de faire fonctionner correctement de nouvelles démos...
Cette démo m'a permis de corriger un problème de calcul d'offset vidéo lorsque le registre R1 du CRTC est modifié en cours de route...
Cette démo en apparence simple m'a donné du fil à retordre. J'ai mis plusieurs jour avant d'avoir un rendu correct. Vous noterez que les effets d’ondulation en bas de l'écran sont mal rendus dans mon émulateur. C'est le sujet évoqué précédemment avec les variations du registre R2 du CRTC. Sur un écran CRT, ça doit créer des effets de vague. Sur un écran LCD, non (ça rend pareil sur un vrai CPC branché à un LCD). Maintenant dois-je "émuler" le rendu d'un moniteur CRT ? La question est ouverte..
Concernant les semaines à venir, je pense passer encore un peu de temps sur le coding du CRTC afin de faire tourner correctement encore 1 ou 2 démos tests mais à un moment je ferai un break afin de retravailler l'ergonomie générale puis le mettre en téléchargement.
Vous en aurez l'exclusivité. Vos premiers retours me seront très précieux pour continuer à l'améliorer.