[EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

[flowstate247]

@Longshot:
Bonjour, J'ai découvert l'existence du CPC CRTC Compendium et du shaker. C'est vraiment fabuleux.
Mais quand je suis sur cette page http://logon.system.free.fr/html/downloadlogon.htm et que je clique sur le lien vers "Portail Shakerland", le lien ne fonctionne pas.

Mon navigateur me renvoie le message suivant :
Hmmm… can't reach this page
Check if there is a typo in shaker.logonsystem.fr.
If spelling is correct, try running network diagnostics with Get Help.
DNS_PROBE_FINISHED_NXDOMAIN

[Longshot]

Bonjour, J'ai découvert l'existence du CPC CRTC Compendium et du shaker. C'est vraiment fabuleux.

Merci pour le compliment.

"Portail Shakerland", le lien ne fonctionne pas.

Oui le lien sur Shakerland est actuellement down et j'en suis désolé.
Nous travaillons sur une mise à jour, et je communiquerais dès que ce sera ré-ouvert.

[Longshot]

Le lien est rétabli, et ce à partir du nouveau nom de domaine pour logon system:
www.logonsystem.eu

[flowstate247]

@Longshot: Parfait, je peux accéder au Shakerland

En parcourant le compendium, il y a une info qui m'a sauté aux yeux. C'est au chapitre 10.3.1 page 74. Il est marqué :

"On peut lire parfois que la modification de R9 sur les CRTC 0 (et 2) n'est pas prise en compte pour
la ligne qui suit celle où la mise à jour a eu lieu car le compteur pour ce registre est "bufférisé".
Le CRTC ne "bufférise" pas ses compteurs. Il teste simplement l’équivalence des compteurs
avec ses registres à des instants très précis.
La seule valeur qui est sauvegardée dans un buffer sur le CRTC est le pointeur vidéo car il est mis
de côté à chaque début de ligne"

C'est très surprenant comme information. Je pensais que justement une des grandes différences du CRTC type 1 était de n'avoir aucun buffer pour ses registres contrairement aux autres types de CRTC.

Donc si je comprends bien, cela veut donc dire qu'aucun CRTC, quel que soit son type, n'a en interne un bufferR4, bufferR5, bufferR9 ?
Je demande pour être bien sûr d'avoir bien compris tellement je suis surpris.

[Longshot]

La plupart de ces vieux circuits faisaient dans l'économie de mémoire.
C4 est associé à R4, R6, R7 et C0 est associé à R0, R1, R2
C9 est associé à R9 et parfois R5 selon le CRTC (Il n'y a pas de C5 sur CRTC 0).
Il n'y aucun compteur alternatif caché.
Ces circuits gèrent de simples égalités qui positionnent des états (sauf le pré Asic et l'Asic).
Le seul compteur "conservé" est VMA' qui est transféré dans VMA en début de ligne.
VMA' étant lui même mis à jour avec VMA lorsque le border de la dernière ligne d'un caractère est atteinte.

J'ai d'ailleurs une petite coquille que je corrige sans attendre.
Il fallait lire.
"La seule valeur qui est sauvegardée dans un buffer sur le CRTC est le pointeur vidéo car il est remis à jour à chaque début de ligne"

[flowstate247]

@Longshot :
En m'étant penché davantage sur la lecture du compendium, je dois dire que si ton travail est absolument remarquable, cela reste un peu hermétique et indigeste pour moi.
Et je dis ça alors que j'ai quand même quelques notions en CRTC. Je n'ose imaginer la tête d'un novice qui essaierait de digérer le compendium. Et dire qu'il ne s'agit que de bêtes compteurs !
Ce qui aiderait beaucoup à la compréhension ce serait d'avoir l'algorithme employé pour chacun des types de CRTC, à la façon de ce que tu as rédigé au chapitre 6 pour le CRTC "idéalisé".
Est-ce qu'il serait envisageable d'avoir ces algorithmes dans une prochaine version du compendium ?

[Longshot]

Le compendium doit te paraitre indigeste si tu as commencé à le parcourir depuis 2 jours (si j’en crois ton 2ème message sur ce portail).
Ce n’est pas un document qui se lit en quelques heures. Certains ont essayé…
Il n’est pas destiné aux novices sur quelques chapitres mais il est néanmoins suffisamment didactique pour qui s’en donne la peine.
Si il sert régulièrement à plusieurs personnes hors et dans le monde CPC, c’est qu’il ne doit pas être si complexe à appréhender.

DManu78 l’a exploité pour Amspirit, et sauf erreur de ma part, il n’avait jamais programmé avant de créer Amspirit.

Le compendium contient pas mal de chapitres généralistes qui ne demandent pas de connaissances particulières, des références historiques et également des informations sur différentes méthodes de programmation (optimisations, techniques de temps fixe) qui pourront paraitre indigestes à un débutant en Z80A ou non connaisseur du monde CPC. Je ne peux pas fournir « d’algorithme crtc » car ça n’a pas de sens au sein d’une architecture aussi spécifique. Si c’était possible la plupart des émulateurs émuleraient aujourd’hui parfaitement les circuits vidéos du Cpc, ce qui est très loin d’être le cas. Et sans une émulation correcte, ces émulateurs sont juste utiles à exécuter une logithèque passée mais ils sont inadaptés pour permettre du cross dev avancé.

Tu indiques avoir quelques notions en CRTC. Quel est ton parcours sur CPC ?

[flowstate247]

Le comportement des différents types de CRTC n'est pas dû au saint-esprit. On peut forcément l'expliquer et le traduire en algorithmes.

Je ne comprends pas ta réaction. Tu as fait l'effort de documenter les différents types de CRTC dans le moindre détail dans un document de 284 pages, mais tu préfères garder les algorithmes sous-jacents pour toi et ne livrer que la version "idéalisée" dans le chapitre 6.

Et dans les autres chapitres, tu expliques les algorithmes utilisés réellement dans les CRTC mais tu le fais seulement sous forme de prose, ce qui est peu adapté au sujet et assez indigeste. C'est ce que je pointe du doigt.

[Longshot]

Le comportement des différents types de CRTC n'est pas dû au saint-esprit.

C'est même certain.

On peut forcément l'expliquer et le traduire en algorithmes.

Oui on peut l'expliquer (ce que j'ai fait) et pour la traduction en "algorithmes", ça s'appelle définir un émulateur.

tu préfères garder les algorithmes sous-jacents pour toi

Je t'ai expliqué pourquoi on ne pouvait pas décrire ces circuits sous cette forme "fonctionnelle" générale.
Tu le sauras lorsque tu auras pris la peine de lire la "prose"
Elle est organisée par registres autour des 3 fonctions majeures du CRTC en tenant compte de l'architecture environnante.

mais tu le fais seulement sous forme de prose, ce qui est peu adapté au sujet et assez indigeste. C'est ce que je pointe du doigt.

Ce que je pointe du doigt, c'est que tu n'as pas pris le temps de lire ma "prose indigeste" alors que tu sembles découvrir mon document depuis peu.
Tu peux continuer à penser qu'on peut étaler des algorithmes "sous jacents" sur un tel sujet et que mon approche n'est pas adaptée si bon te semble.
Mais évite de me faire un procès d'intention sur le fait de "garder des choses pour moi" intentionnellement.
Je n'ai jamais eu cette philosophie.

Mon approche a été réfléchie, concertée, et est la plus adaptée pour décrire toutes les subtilités liées à ces circuits et en énumérer les différences.
Le document est étayé d'exemples concrets et accompagnés de très nombreux schémas qui mettent en relief des sujets complexes impossibles à décrire par quelque "algorithme" que ce soit. C'est notamment le cas sur l'interlace, les synchros, les intéractions diverses avec le Z80A, le GA, et les centaines de détails ou bugs des circuits décrits dans des différents contextes précis.

[Dmanu78]

Je ne vais pas rentrer dans la polémique mais je me permets d'intervenir car le travail effectué par @Longshot sur le fonctionnement interne des différents CRTC équipant le CPC est juste énorme et c'est une chance d'avoir sous la main le fruit d'un tel travail distribué librement à la communauté ... et sans aucune contrepartie. Il ne faut pas l'oublier. Sachant cela, accuser Longshot de garder pour lui les "algorithme sous-jacents" est d'une mauvaise foi consternante. Si les centaines de pages du compendium pouvaient être résumés dans un diagramme, Longshot l'aurait fait depuis longtemps.

Il est quand même assez paradoxal de se plaindre d'avoir un document trop détaillé alors qu'en général on se plaint du contraire...
N'oublions pas que jusqu'à la sortie du compendium, c'était la grosse galère pour trouver des infos détaillées sur le fonctionnement du CRTC. Il n'existait que de brides d'informations éparses, éparpillées dans divers forum (voire jalousement gardés entre initiés) et il fallait coder l'émulation avec ses rares informations et les datasheet officiels (donc très succincts) et souvent déduire de nouvelles règles de fonctionnement à partir de l'analyse des démos (si vous me suivez depuis l'origine, c'était ma méthodologie de départ)...Pas extra pour établir un émulateur fiable et précis.

Le compendium est avant tout une doc technique détaillant avec une extrême précision le fonctionnement de la partie vidéo (et plus) du CPC. Comme toute documentation technique, sa lecture n'est pas à la portée du néophyte car il faut maitriser certains concepts, je le conçois. Néanmoins, avec un peu de travail et de persévérance, il est parfaitement exploitable. Amspirit s'appuie à 100% dessus. Je ne me considère pas comme un génie mais j'ai pu l'exploiter sans (trop) de difficulté pour écrire l'émulation du CRTC dans AmspiriT en (re)partant de zéro...

Maintenant mettre en algorithme le contenu du compendium n'est pas vraiment réaliste. Le CRTC est loin d'être un simple "compteur". Le développement de l'émulation des 4 CRTCs à partir du compendium m'a pris environ 1 an et demi de boulot (et ce n'est pas encore terminé, il reste toujours des bugs résiduels). Il m'a fallu entre entre 3 à 6 mois développement par CRTC. Il y a de nombreux "trigger" et d'interconnexion dans chaque CRTC avec de nombreux effets de bord, limite bug de conception (surtout sur le CRTC "1") , lorsque l'on se trouve "hors" des spécifications des datasheet. Il faut compter aussi avec des influences "extérieures" au CRTC qui conditionnent son comportement (par exemple écrire dans les registres du CRTC avec une instruction OUT ou OUTI dans les mêmes timing ne va pas provoquer le même résultat dans certains cas) et tenir compte du fait que chaque CRTC a un temps de réaction qui lui est propre et qui va conditionner ses signaux de sorties. Tout cela est parfaitement documenté dans le compendium.

Allez, un autre petit exemple pratique pour illustrer mes propos, prenons la démo "Camembert 4" qui a déjà été évoquée précédemment. Cette démo a la particularité de provoquer 2 signaux horizontal HSYNC en milieu d'écran pour changer le mode d'affichage. On a donc du mode 1 et mode 0 qui cohabitent sur une même ligne. Or si vous regardez attentivement l’image sur un vrai CPC vous constaterez une petite bizarrerie visuelle.



Sur un vrai CPC, il y a un demi-octet affiché en trop (on le voit après le G de MEETING). Ce comportement est du au fait que le CRTC envoie le signal HSYNC au Gate Array quelques seizièmes de Mhz après que son compteur interne ait atteint le registre R2, le traitement du signal n'est pas instantané (et ce délai varie entre les CRTC !!). Sur la plupart des émulateurs que j'ai testé, cette latence n'est pas prise en compte et même sur la page de téléchargement du site CPC-POWER, l'image est fausse car prise sur un émulateur certainement !

https://www.cpc-power.com/index.php?pag ... l&num=7737


Amspirit émule fidèlement la démo par rapport au rendu d'un vrai CPC...

Alors oui, dans 99,99% des cas, ce "défaut visuel" ne se verra jamais puisque le signal HSYNC est émis hors limite visible de l'écran et des esprits (très) chagrins pourront m'accuser effectivement d'être un peu trop pinailleur en me focalisant sur plein de petits détails insignifiants. Mais je l'assume car c'est ma philosophie de l'émulation..tendre sans compromis au plus près du comportement de la machine réelle, peu importe le cout (et ceci explique aussi accessoirement pourquoi AmspiriT consomme autant de CPU, prendre en compte tous ces petits détails a un prix en terme de ressource).

Ainsi vous l'avez compris, je me focalise actuellement à régler le moteur d'émulation à la vis micrométrique... Mais ce n'est qu'une étape, même s'il s'agit de la plus importante...Je me focaliserai un peu plus tard sur la carrosserie et les fonctionnalités annexes après. Je ne suis pas pressé et je prendrai le temps de faire les choses bien. Le meilleur reste à venir.

[Markerror]

Pinailler, c'est un des principes de base du bon démo-maker . Il y a (quasiment) toujours moyen d'améliorer une routine, un effet, de le rendre plus rapide. C'est valable pour le code mais aussi pour les graphismes et la musique.
Ca explique en partie pourquoi certaines productions peuvent mettre des années à sortir.

Mince, on dirait que le monde de la démo a inventé le principe de l'"amélioration continue", concept cher aux entreprises (et l'a mis en pratique surtout ).