[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

Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par 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.
Dernière modification par hlide le 17 mars 2021 13:00, modifié 1 fois.
Avatar de l’utilisateur
adnz
Messages : 213
Inscription : 10 janv. 2010 00:07

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par adnz »

Impressionnant pour moi ceux qui programme des émulateurs. :shock:

sinon moi je propose AMSTRADAMUS ou ABRACADAMTRAD pour le nom :D
Avatar de l’utilisateur
Sebiohazard
Messages : 425
Inscription : 30 avr. 2019 15:07

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Sebiohazard »

adnz a écrit : 17 mars 2021 08:35 (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 :lol: :lol: :lol:
Image
Dmanu78
Messages : 268
Inscription : 20 juin 2020 14:28
Localisation : Yvelines

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par 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 :

Image
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 :

Image
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.

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

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

Image
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 :D Merci à vous.
Dernière modification par Dmanu78 le 08 avr. 2021 20:52, modifié 5 fois.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par __sam__ »

Vu la quantité de travail astronomique je l'appellerais AMStronomous.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Avatar de l’utilisateur
adnz
Messages : 213
Inscription : 10 janv. 2010 00:07

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par 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.
Avatar de l’utilisateur
Kristof
Messages : 367
Inscription : 08 mars 2021 10:44
Localisation : Narbonne (11)
Contact :

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Kristof »

Bravo a toi, sacré travail dis donc.
Markerror
Messages : 2121
Inscription : 31 oct. 2011 19:21
Localisation : Orléans
Contact :

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par 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.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par hlide »

Voici le diagramme pour l'accès au port I/O :
Z80 I_O cycle.png
Z80 I_O cycle.png (109.05 Kio) Consulté 4181 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
463324_1_En_10_Fig2_HTML.gif (40.42 Kio) Consulté 4181 fois
Là on a vraiment l'impression que c'est T2 qui est allongé.
Dmanu78
Messages : 268
Inscription : 20 juin 2020 14:28
Localisation : Yvelines

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Dmanu78 »

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

@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.. :wink:

@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 :)
Dmanu78
Messages : 268
Inscription : 20 juin 2020 14:28
Localisation : Yvelines

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Dmanu78 »

Quelques petites nouvelles de l'avancement de l'émulateur...

Ces dernières semaines j'ai encore passé beaucoup de temps à travailler sous le capot afin de parfaire l'émulation du CRTC, du Gate Array (GA) et de la puce sonore. Et j'ai donc passé beaucoup de temps sur de nouvelles démos...

Depuis le temps que je travaille à affiner le rendu du CRTC, je suis toujours impressionné (ou désespéré) de voir que chaque nouvelle démo passant mes étapes de tests recèle une nouvelle technique de rendu nécessitant une adaptation de mon code. Les possibilités d'exploitation de ce composant semblent infinis... Mais néanmoins, il me semble voir venir le bout du tunnel. Les toutes dernières démos que j'ai testées semblent tourner sans gros bugs visuels, signe que l'émulateur commence à être enfin mature (du moins pour la version "0", je rappelle que le CPC peut aussi avoir les versions 1 ou 2, avec des comportements subtilement différents).

Qui peut le plus peut le moins. Fort de ce vieil adage, je me suis attaqué à une démo réputée très technique, la "MADNESS DEMO" de GOZEUR. Et je n'ai pas été déçu du voyage car avec cette démo on touche au monde de l’extrême sur CPC. Il m'a fallu plus de 2 semaines de recherches et de tâtonnements avant de comprendre son fonctionnement et de pouvoir l'émuler correctement. Cette démo pousse le couple CRTC/GA dans ces derniers retranchements avec des comportements extrêmes que je n'avais encore jamais rencontrés : d'un côté elle se permet de laisser flotter l'affichage sur quelques lignes en n'émettant pas de signal HSYNC au moniteur pendant plusieurs lignes (alors qu'il faut un signal de saut de ligne tous les 64 µs), laissant le moniteur faire lui même sa propre synchro et ensuite elle envoie 3 signaux de HSYNC par ligne pour provoquer des ruptures (pour forcer un changement de résolution au sein de chaque ligne). Dans ces conditions, ça devient un challenge de réussir à resynchroniser correctement le signal pour former une belle image à l'écran. Le timing doit juste être parfait, à la µs près sinon l’affichage devient distordu. A force d'essais, j'ai enfin réussi à rendre correctement cette démo (du moins par comparaison avec les screenshots que j'ai pu voir car je n'ai pas réussi à la visualiser avec mon vrai CPC l’adaptateur SCART <=> HDMI n'aime pas du tout ce genre de bidouilles sur les signaux de synchro). Au final, cette démo m'a permis de corriger plusieurs bugs sur l'émulation du CRTC dans ces cas extrêmes et m'a obligé à ajouter un petit "patch" afin d'émuler le comportement d'un moniteur CRT en forçant un retour à la ligne écran suivante dès lors qu'un signal HSYNC n'est pas émis dans les 64 µs...Heureusement, cela restera un cas particulier puisque cette démo n'a quasiment pas d'équivalent par ailleurs. Néanmoins, à travers la résolution de son rendu, elle m'a permis de lancer avec succès d'autres démos basées sur la même technique de rupture ligne à ligne.

Dans la foulée, la recherche de résolution de bugs a été fructueuse puisque qu'en résolvant un dysfonctionnement sur une démo, j'ai pu corriger un gros "bug" touchant cette fois l"émulation du Z80. C'est assez surprenant car c'est une partie du code que je ne touche quasiment plus, l'émulation du z80 est certainement la partie la plus robuste de mon code... mais pas encore suffisamment on dirait. Le bug en question n'était pas bloquant mais se traduisait sur certaines démos par des ralentissements/désynchronisation du rendu sonore par rapport au rendu visuel. Ce sont des bugs très compliqués à débusquer et je n'avais jusqu'à présent pas de pistes précises pour commencer mes recherches. Et, heureuse surprise pour moi, les manifestations de ce bug sont apparues très clairement sur une toute petite démo sans prétention qui trainait dans mon stock depuis plusieurs mois et qui se caractérisait par une musique...très ralentie. Juste ça. En pistant l'appel à la routine mettant à jour les registres de la puce sonore, je me suis aperçu qu'elle n'était pas appelée aussi fréquemment qu'elle le devrait ... car le z80 "oubliait" parfois de traiter le signal d'interruption /INT généré par le Gate Array toutes les 52 lignes écran. Le coupable était enfin trouvé...la résolution a ensuite été très rapide. Le problème venait en fait de l'absence de traitement des requêtes d'interruption pendant l'exécution des instructions "BLOC" du z80 (LDIR notamment). J'attendais tout simplement la fin de l'instruction pour traiter l'interruption au lieu de la traiter pendant l'exécution de cette instruction. En regardant rapidement ma doc de référence sur le z80 "The Undocumented Z80 Documented" j'ai eu la confirmation que c'était bien ça le comportement normal. Et par magie, nombre de démos qui dysfonctionnaient se sont mis à fonctionner parfaitement après la mise en place du correctif. Une chasse finalement très fructueuse que celle là :)

En parlant de rendu sonore, j'en ai profité pour me replonger dans la partie relative à l'émulation du AY. Cela fait des mois que je croyais cette partie du code terminée. Je me trompais... encore. En comparant le rendu de certaines musiques de mon émulateur avec celui d'autres émulateurs renommés (Caprice 64, WinApe et SugarBox, car oui maintenant je regarde ce que font mes petits camarades :) ), je me suis aperçu que ça ne sonnait pas tout à fait pareil à l'oreille dans des cas bien précis, et notamment lorsque l'enveloppe de volume du AY variait très rapidement. Ma gestion des variations d'enveloppe était incorrectement implémentée. J'ai donc apporté des modifications à ce niveau là et le rendu sonore me semble bien plus conforme maintenant. En vérité, il faudrait maintenant que j'implémente des filtres hautes et basses fréquences car mes graves & aigus rendent trop forts par rapport au médium. Si quelqu'un avait sous la main la courbe d'atténuation du spectre sonore d'un CPC sur les fréquences "audibles" 20 Hz - 20 khz, ça me rendrait bien service. :wink:

Maintenant quelques images pour accompagner ce long texte :

Image
La voilà enfin cette très technique démo "MADNESS". Sur la partie haute de l'écran, vous noterez que le "ZZTOP" est en mode 1 (320*200 - 4 couleurs) alors que "GOZEUR" est en mode 0 (160*200 - 16 couleurs) et le tout sur les mêmes lignes. Une belle prouesse qui montre que le CPC a de la ressource.

Image
La même démo avec d'autres techniques de rendu. Très joli au final, surtout en mouvement et le tout à 50 images/s bien sur.

Image
Une autre démo "SCROLL FACTORY" exploitant la même technique de rupture mais de manière très subtile. Si vous regardez bien, la partie gauche de l'image est en mode 1 et la partie droite en mode 0.. Une belle prouesse technique et esthétique.

Image
Encore plus fort sur cette même démo, les 3 résolutions du CPC sur la même ligne (textes en blanc : résolution en mode 0 (160*200), mode 1 (320*200) et mode 2 (640*200) de gauche à droite de l'écran. Je n'ai jamais vu ça ailleurs...

Image
Une autre démo exploitant cette technique "CAMEMBERT 4" (oui, c'est son nom) avec du mode 1 et du mode 0. Notez qu'elle n'est pas encore parfaitement rendue. J'ai un petit décalage de rendu d'un octet..quand je vous dit que ça ce joue à la µs près...

Image
Une autre démo plus classique "SYNERGIE 2" évoquée par @Markerror qui m'a permis de corriger un autre bug sur le CRTC...Un de plus.

Image
Enfin, une jolie démo à voir en mouvement et qui m'a permis de corriger 2 bugs de rendu au niveau du CRTC et du Gate Array.

Ces dernières semaines ont donc été assez fructueuses et l'émulateur commence à gagner en robustesse et en précision d'émulation. Je vais terminer de corriger le rendu d'une ou deux démos et me mettre en pause afin de travailler le "front" et l'ergonomie de l'émulateur pour la diffusion d'une première béta.

Oh j'allais oublier, "one more thing", petite surprise de fin de post, je crois lui avoir enfin trouvé un petit nom de baptême qui me plait bien : "AMSpirit" (le mot "spirit" à plusieurs sens en anglais. Le plus direct est "soul" pour retrouver l'âme "AMSTRAD" à travers cet émulateur mais peut aussi être employé pour signifier "enthusiam / determination" qui représente bien mon état d'esprit sur ce projet personnel un peu fou ). :D . C'est plutôt sympa au final, non ? :wink:
Brochiman
Messages : 3405
Inscription : 02 juin 2019 11:26
Localisation : Angers

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Brochiman »

Je vote pour AMSpirit 😊😊👍👍
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par __sam__ »

AMSpirit au sens Amstrad soul.. Faut faire attention et pas confondre avec l'émul de coupé, le SAMsoul, que j'ai jamais fini parce que SAMsoul quoi :lol:

P.S. c'est une connerie pour le jeu de mot bien évidemment.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Markerror
Messages : 2121
Inscription : 31 oct. 2011 19:21
Localisation : Orléans
Contact :

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par Markerror »

Bonjour,

Beau boulot et lecture très intéressante. Pour le coup du bug Z80, c'est assez normal que cela soit sur une "petite" demo que tu ais détecté le bug, les LDIR sont normalement peu utilisés pour faire des décalages mémoire (moins rapides que des séries de LDI pour un scrolling par exemple).

A noter que la demo de Gozeur ne fonctionne correctement que sur CRTC 1. Il avait bricolé une version à l'époque où on pouvait jouer sur les timings pour essayer de faire une adaptation pour les autres modèles, mais c'était imparfait (on avait en particulier des effets d'escaliers... ).

Concernant l'émulation AY, tu peux essayer la première démo de Vanity, From scratch. Le début de la musique est souvent malmené par les vieux émulateurs (c'est bon sur CPCEC et sur la version 2.0 de Winape).

Sinon, une nouvelle megademo est sortie à la Revision 2021, Can Robots Take Control. Ca peut valoir le coup de la tester :-).
Dernière modification par Markerror le 28 avr. 2021 22:03, modifié 1 fois.
Avatar de l’utilisateur
6502man
Messages : 12286
Inscription : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: [EMULATION AMSTRAD CPC] work in Progress

Message par 6502man »

Super boulot d'émulation du CPC, bravo :D
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.
Répondre