[EMULATION AMSTRAD CPC] work in Progress

[hlide]

Eh oui. Si tu as un moniteur qui ne prend pas la fréquence à la source, tu auras un décalage qui ne rendra pas fluide un scrolling. Un exemple, tu affiches deux couleurs alternées par frame (sur un vrai CRT, ça construit une nouvelle couleur mais avec un scintillement proportionnelle à la différence de luminance entre ces deux couleurs), ben ça rend très mal sur un LCD pour la même raison : différence de fréquence. Le seul moyen que j'ai trouvé, faire du blending entre deux frames par l'émulateur.

[adnz]

Impressionnant pour moi ceux qui programme des émulateurs.

sinon moi je propose AMSTRADAMUS ou ABRACADAMTRAD pour le nom

[Sebiohazard]

(supp modo: quote inutile)

Pareil pour moi quand je vois les heures que je passe pour essayer d'apprendre le langage C & pour écrire un petit programme de 65 lignes & qu'ensuite je regarde le code source d'un émulateur Amiga, pour lequel il est écrit plusieurs milliers de lignes de code RIEN que pour le CPU j'hallucine !!!

Excellent AmstraDamus

[Dmanu78]

Quelques petites news fraiches de l'état d'avancement de l'émulateur.

J’ai passé ces derniers temps à améliorer l'émulation du CRTC, qui me prend décidément beaucoup (trop) de temps, en me penchant sur des démos très techniques et extrêmement exigeantes sur le respect des timings. C'est dans ces situations en utilisation extrême que l'on se rend compte que l'émulation en T-States a son intérêt mais aussi ses limites car il y a tellement de combinaisons possibles pour trouver un bon timing que ça en devient terriblement complexe. On rentre dans du réglage de précision, inférieure à la microseconde.

Ces 2 dernières semaines je me suis attaqué aux démos "S&KOH" et "overflow Previews" du groupe LOGON qui exploitent le CRTC dans ses derniers retranchements en utilisant des techniques hard de rupture vidéo de seulement 2µs !. Dans ces 2 demos, le registre R0 du CRTC fixant la durée d'une rasterline est mis à la valeur "1" (soit 2 µs) là où normalement il est fixé à &3F, soit 64 µs. Avec cette valeur extrême, qui est inférieure à la durée d'exécution de certaines instructions du Z80, toute durée d’exécution anormalement courte ou longue d'une instruction Z80 de moins de 1 microseconde va se traduire par un mauvais incrément du registre R9 du CRTC (gérant les scanlines) et par un défaut visuel au final.
Pire, toute la justesse de l'émulation va se faire en fonction du timing d'exécution au sein de l'instruction OUT elle-même modifiant la valeur du registre R0 du CRTC. 1T-states de décalage entre l'exécution de l'instruction OUT du Z80 et la modification du registre R0 du CRTC et le résultat devient foireux.

Je disais que l'usage du T-state est complexe car pour atteindre cette précision, il y a plusieurs moyens : Modifier le compteur de cycle tWait du Gate-Array (3 cycles Twait actifs sur 4 => 4 possibilités de moduler la temporisation du Z80 !), inverser les signaux 1 Mhz HAUT<=>BAS alimentant le CRTC, modifier l'emplacement de l'extraWait dans l'instruction OUT du Z80 (je ne sais toujours pas s'il est en T2 ou T3..ça a un impact minime dans l'émulation mais c'est indispensable au bon rendu visuel), modifier l'emplacement de la routine de mise à jour des registres du CRTC dans le CRTC lui_même, buffériser certains compteurs...en jouant sur ces paramètres un par un ou sur plusieurs à la fois.
Les combinaisons possibles deviennent faramineuses pour trouver UN bon réglage de timing sachant que ça peut casser une autre démo qui marchait très bien avant...Et il faut tout refaire.
A force de tâtonnements et de multiples (et subtiles) modifications du code dans le Z80/CRTC et le Gate Array (tous les 3 trois ensemble !) , j'ai réussi à trouver un compromis "satisfaisant" mais pas parfait puisque j'ai dû me résoudre à mettre une petite "verrue" dans le CRTC pour gérer ces cas extrêmes... Un patch de fortune qui n'est jamais satisfaisant mais à ce jour, je n'ai pas encore trouvé le réglage ultime...

au final, plusieurs petites démos se sont ajoutées à ma liste, ce qui m'aura également permis de corriger de nouveaux petits bugs de rendu. Petit à petit l'émulateur gagne en précision...

Petites nouveautés :


Et la voilà cette très jolie et très technique démo S&KOH. Elle se mérite.

Dans la même veine, la ou plutôt les 2 démos de "Overflow préviews", très techniques également :


Une démo de "shadow of the beast" du plus bel effet avec un scroll en parallaxe sur plusieurs niveaux parfaitement fluides et avec musique en plus. Le CPC est une sacrée machine.


Une autre démo à "R0 = 1" particulièrement compliquée à rendre correctement.


@markerror. La démo "Tire au flan" enfin rendue correctement. Les effets visuels sont très jolis.


Une autre démo sympa. Octopus-pocus. Il reste un défaut de rendu sonore à résoudre sur cette démo.

Voilà à ce jour l'état d'avancement de l'émulateur.
Comme je le disais précédemment, je vais terminer de corriger quelques démos et vais retravailler sur l'ergonomie générale pour commencer à la distribuer. Je ne me suis toujours pas décidé sur son nom mais ça fait plaisir de voir que certains travaillent dur à lui trouver un petit nom Merci à vous.

[__sam__]

Vu la quantité de travail astronomique je l'appellerais AMStronomous.

[adnz]

Incroyable j'avais jamais suivis comme ça un dev d'un émulateur presque en live... ça l'air de bien fonctionner ...

Juste en tant qu'utilisateur de pas mal d'émulateur check bien l'ergonomie pour le setting des touches et des controllers (manette),
c'est toujours le truc super relou sur certain émulateur, genre super chiant à paramétrer et des fois ça garde pas le setting bref, c'été juste une remarque qui peut faire zapper l'utilisateur ...

cool.

[Kristof]

Bravo a toi, sacré travail dis donc.

[Markerror]

Bonjour,

Faire tourner la S&Koh, c'est déjà un achèvement . Pour la petite histoire, Grim a malicieusement glissé un clône dans une autre démo, Synergy 2.

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

Je crois que la méthode de programmation des ruptures est un peu différente.

[hlide]

Voici le diagramme pour l'accès au port I/O :

Z80 I_O cycle.png (109.05 Kio) Consulté 307 fois

"l'extraWait" n'est ni dans T2 ni dans T3, il est est entre les deux. Suivi par des wait states supplémentaires si nécessaire. Tu noteras que le /WAIT n'est pris en compte qu'après le Tw* et non le T2 ou si tu préfères comme si on allongeait Tw* et non T2.

Après je comprends ta question :

463324_1_En_10_Fig2_HTML.gif (40.42 Kio) Consulté 307 fois

Là on a vraiment l'impression que c'est T2 qui est allongé.

[Dmanu78]

@ Sam
Au moins c’est un nom original. Vous êtes très imaginatifs

@adnz
Tu as tout à fait raison. J’avoue que je ne me suis pas encore penché sur la personnalisation du Mapping des touches (il y a juste un mode par défaut fixé en interne) ni sur celle du joystick/pad..C’est dans ma TODO list..

@markerror
Merci du compliment. S&kOH est en effet une démo très exigeante qui m’a pris pas mal de temps pour être bien rendue. A elle seule, elle m’a permis de corriger 3 bugs d’affichage dont 2 rien que sur le Gate Array (comme le fait que le GA réactive tout seul l’affichage 6 microsecondes après le signal Hsync du CRTC...).. . Je vais regarder la démo en lien

@hlide
Beaucoup merci pour ces précieuses informations. C’est très intéressant, j’avoue que je n’ai pas testé cette combinaison tw* suivi de /Twait ; je vais regarder ça ce soir