[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
ThomasR
Messages : 39
Inscription : 16 janv. 2019 09:02

Re: [EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Message par ThomasR »

Hello Dmanu!
Dmanu78 a écrit : 29 nov. 2021 00:10(...)
@ThomasR : It's a pleasure. Tell me the results of your tests :)(...)
Thanks again for your work!
I did not many tests, only one demo (from an A side) and three programs (from a B side :D ).
On my other machine (with Intel CORE2 Duo P7450 2.13GHz) the emulator runs fine, with the speed of the original hardware. On the AMD machine it still runs much slower.
v0466.png
v0466.png (136.85 Kio) Consulté 6350 fois
Do you already know this Christmas demo? I wish you a nice Christmas time!

Best regards,

Thomas
Pièces jointes
demonoel.zip
rename
to demonoel.dsk
(190.25 Kio) Téléchargé 104 fois
Dmanu78
Messages : 268
Inscription : 20 juin 2020 14:28
Localisation : Yvelines

Re: [EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Message par Dmanu78 »

Hello ThomasR
I didn't know this demo; it's the Christmas spirit :)

For AMD processor performance, have you tried to change the video refresh option in the configuration menu?
Image

This "may" change the CPU load but I'm not sure of the real impact.Let me know if there is any influence on the emulation speed :wink:
Avatar de l’utilisateur
ThomasR
Messages : 39
Inscription : 16 janv. 2019 09:02

Re: [EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Message par ThomasR »

Dmanu78 a écrit : 01 déc. 2021 22:49(...)For AMD processor performance, have you tried to change the video refresh option in the configuration menu?
This "may" change the CPU load (...)
Hello Dmanu,

the emulated machine was in this mode (THREAD), both other modes ar as slow. Don't waste your time and energy to this problem any longer, it is not that important.
KLAX_etc.png
KLAX_etc.png (96.05 Kio) Consulté 6280 fois
I tested three other programs (one of them using overscan).
This little program
hiver.ZIP
rename to hiver.bin
(2.07 Kio) Téléchargé 101 fois
from the journal CPCAI 12-92/1-93 produces the picture of the winter forest. You can use it as a screen saver - the snowflakes are moving and you can hear the wind blow.

Best regards,

Thomas
Lone
Messages : 16
Inscription : 26 nov. 2020 09:53

Re: [EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Message par Lone »

Dmanu78 a écrit : 29 nov. 2021 00:10 @lone.
Merci pour la proposition de cette liste de non régression. ça me sera très utile effectivement. Je ne teste que par échantillonnage "aléatoire" pour l'instant et je pense avoir encore pas mal de soft protégés non testés. On peut se MP si tu veux pour la suite :)
Hello, le week end arrivant, j'ai pu zipper & déposer une archive contenant un pack qui me sert à tester mes modifications FDC ou de gestion du format dsk.
Le lien est le suivant : https://we.tl/t-rMflPf9puq
Tous ces dumps sont réputés fonctionner correctement, certains étant assez tordu.
Dmanu78
Messages : 268
Inscription : 20 juin 2020 14:28
Localisation : Yvelines

Re: [EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Message par Dmanu78 »

@Thomas R
Thanks for yours tests. It's nice to see the emulator in action :)

@lone.
Un énorme merci pour cet ensemble de jeu de tests. Je vais le garder précieusement. J'ai fait quelques tests rapides, je dois avoir autours de 50% de changement en échec.. Bon, j'ai encore pas mal de pain sur la planche on dirait mais ça va bien super m'aider pour structurer mes tests .. :)

Sinon, en échangeant sur le forum de CPC Rulez, on vient de me signaler une belle surprise : "Longshot", LA légende de la programmation sur CPC, un "dieu" vivant pour certains CPCistes :D , vient tout juste de sortir un guide complet en Français de 170 pages (!) sur le fonctionnement des différents modèles de CRTC équipant les CPC.
Je viens de le parcourir, c'est énorme, une véritable bible ce document, le MUST HAVE pour tout développeur d'émulateur CPC. Quand je pense que j'ai passé plusieurs mois à glaner la moindre bribe d'informations sur le fonctionnement intime de cette puce, à tâtonner, à décortiquer le fonctionnement des démos pour en tirer quelques secrets et là, ça arrive tout d'un coup, un guide complet, structuré, avec les spécificités de chaque type ... le rêve absolu !! :o A la lecture du document, vous comprendrez mieux pourquoi on passe autant de temps à parfaire l'émulation du CRTC :D
Il est gratifiant de voir qu'il reste de vrais passionnées du CPC plus de 35 ans après sa commercialisation...

https://cpcrulez.fr/forum/viewtopic.php?p=57255#p57255

En complément, Longshot nous gratifie d'une nouvelle démo avec une toute nouvelle technique de rupture vidéo inédite sur CPC, applicable sur l'ensemble des modèles de CRTC, c'est presque du jamais vu. Bilan pour mon émulateur, 3 bugs détectés dans l'émulation du CRTC, 1 pour chaque modèle de CRTC 0,1,2 : pas de jaloux lol... et 1 bug sur le FDC détecté...Bigre, tout cela sur une seule démo..

Image
Remake de la démo "Amazing démo" 30 ans plus tard, compatible tout type de CRTC.. A noter que j'ai du corriger quelques bugs pour en arriver là. La version actuellement en téléchargement n'est pas compatible...Un peu de patience. :D

Et en prime, il nous met à disposition un jeu de tests "ACID" pour tester l'émulation du CRTC dans ses moindres recoins...
http://logonsystem.fr/html/engdownloadlogon.htm

Je croyais avoir particulièrement bien émulé le CRTC et bien, je dois rester humble, je suis encore à des années lumières d'avoir implémenté toutes les subtilités de ce chipset. Ce test est particulièrement cruel, moi qui croyais en avoir quasi-terminé. Snif !! Mais je ne boude pas mon plaisir, je vais pouvoir occuper sainement mes soirées hivernales... :D
Longshot
Messages : 15
Inscription : 10 déc. 2021 15:58

Re: [EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Message par Longshot »

Salut Dmanu78

J'ai ajouté 14 instructions aux 3 qui étaient déjà traitées dans le test 1 de SHAKER.

Version 1.9 avec les fichiers de référence disponibles ici : http://logonsystem.fr/html/engdownloadlogon.htm

A noter que sur ce type de test, tous les CPC se valent (CRTC 0.1.2.3.4).
(Donc un seul document de référence suffit)

Cela devrait te permettre d'améliorer le code qui simule le Z80A. :wink:

Bon courage!
Dernière modification par Longshot le 10 déc. 2021 18:37, modifié 1 fois.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: [EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Message par hlide »

Le lien donne sur une page d'erreur "Not Found".
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Message par Daniel »

Il faut enlever le "l" de html à la fin de l'URL : http://logonsystem.fr/html/engdownloadlogon.htm
Daniel
L'obstacle augmente mon ardeur.
Longshot
Messages : 15
Inscription : 10 déc. 2021 15:58

Re: [EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Message par Longshot »

Corrigé. Merci pour la remarque.
Dmanu78
Messages : 268
Inscription : 20 juin 2020 14:28
Localisation : Yvelines

Re: [EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Message par Dmanu78 »

Un grand merci à toi @longshot pour ces nouveaux jeux de test dans cette nouvelle version de SHAKER. :D

J'adore ce petit test puisqu'il permet de mesurer très précisément les timings d'écriture d'une instruction z80, à partir d'un point de départ fixe pour avoir toujours la même référence.

Longshot me reprendra, étant l'auteur de ce test, mais si j'en ai bien compris le principe, chaque instruction est répétée plusieurs fois avec une adresse d'écriture décalée d'un octet (=1microsenconde) dans la mémoire vidéo. Cela permet de connaitre le moment précis où l'écriture est effectuée en mémoire au sein d'une instruction.
C'est ce test extrême qui permet de découvrir l’intérêt d'écrire un émulateur en T-states puisque la réussite à ce test nécessite de suivre à la lettre les timing des cycles FETCH / READ / WRITE au sein des instructions z80. il permet aussi de contrôler la bonne synchronisation des accès mémoires entre z80<=> GateArray<=>CRTC.

Vous me connaissez, la curiosité m'a titillé et je viens de faire un petit test sur le version 1.9

Image
Pour comprendre le test : 2 barres verticales "vides " = valeur 0 en mémoire / un rectangle noir = valeur #FF en mémoire / Rayure = valeur #55.
Pour l'instruction EX (SP), HL, on écrit à l'adresse du registre SP (qui est décalé d'une µs à chaque ligne) la valeur "HL = #FF55"
Ouf, les tests effectués avec l’émulateur semble en accord avec les copies d'écran issues d'un vrai CPC.

J'ai juste noté une erreur sur l'instruction EX (SP), HL pour laquelle j'avais, semble-t-il, inversé l'ordre d'écriture en mémoire entre l’octet de poids fort et de poids faible... Ce n'est pas documenté et seul ce test permet de comprendre comment le z80 effectué ses accès en mémoire.

Image
Un petit exemple pratique pour l'instruction EX (HL), SP : l'erreur que j'avais provenait de la partie entourée en jaune dans mon code source. J'écrivais en mémoire l'octet de poids faible (registre L) puis l'octet de poids fort (registre H), ce qui est la logique normalement. En fait, il semblerait que le z80 écrive d'abord l'octet de poids fort avant d'écrire l'octet de poids faible en mémoire. Seul ce test permet de découvrir ce petit secret...

A ce stade, je me permets donc de sortir une nouvelle version de l'émulateur v0.473b, corrigeant les premiers bugs de rendu du CRTC modèle 0,1 et 2, un décalage de timing sur le cycle WRITE du z80, une mauvaise initialisation des instructions SEEK et CALIBRATE du FDC; Avec cette version, vous pourrez également profiter de la dernière version de "AMAZING DEMO" de Longshot...tout CRTC confondu (enfin je crois) :wink:
C'est en première page que cela se passe... :D
Longshot
Messages : 15
Inscription : 10 déc. 2021 15:58

Re: [EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Message par Longshot »

@Dmanu78. Tu as parfaitement décrit ce que fait ce test.

Merci pour le partage du code d'émulation de l'instruction.

Concernant EX (SP),HL, il me semble que c'est indiqué dans le datasheet Zilog dans cet ordre (H puis L).

Je suis curieux de voir à quoi ressemble le code d'émulation du OUT (C),r8 et celui du OUTI si ça ne t'ennuie pas.
Dmanu78
Messages : 268
Inscription : 20 juin 2020 14:28
Localisation : Yvelines

Re: [EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Message par Dmanu78 »

Un petit état d’avancement de l’émulateur. Il est actuellement capot ouvert pour réécriture de l’émulation du couple CRTC-GA. Le guide de Longshot m’a permis de découvrir que j’avais fait fausse route sur certains aspects de l’émulation de la vidéo et que j’avais patché inutilement certaines parties de mon code. Je repars donc sur des fondations plus saines.
Avec la précieuse assistance de Longshot ( je suis gâté), ça fait donc un bon petit mois que je réécris complètement la partie concernant l’émulation du CRTC type 0 (et juste celle là, il restera les 2 autres à faire ensuite !) et je commence à avoir des résultats intéressants sur les cas les plus extrêmes, qui ne passaient pas avec l’ancienne version du code, avec un code plus universel, plus compact et beaucoup moins complexe. Dans la foulée, la précision du moteur de rendu vidéo a été poussée au 1/16 MHz (contre 1/4 MHz auparavant) permettant d’afficher des subtilités de rendu comme l’avance de l’affichage d’un pixel en mode 2 par rapport aux autres modes vidéos.
Il y a également en parallèle un travail de vérification de la non régression par rapport à la version actuelle : c’est assez fastidieux puisque je commence à avoir dans ma boîte à outils plusieurs dizaines (centaines) et programmes&démo à revérifier…

La contre-partie est que ces évolutions coûtent encore plus de ressources CPU, entre 30 et 40% en plus. Les utilisateurs qui étaient limites avec la version actuelle de l’émulateur le seront encore plus avec celle à venir…
Bref, le développement suit son cours….pour le meilleur je l’espère. :)
Avatar de l’utilisateur
Sebiohazard
Messages : 425
Inscription : 30 avr. 2019 15:07

Re: [EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Message par Sebiohazard »

Dmanu78 a écrit : 10 janv. 2022 14:32 La contre-partie est que ces évolutions coûtent encore plus de ressources CPU, entre 30 et 40% en plus. Les utilisateurs qui étaient limites avec la version actuelle de l’émulateur le seront encore plus avec celle à venir…
Salut Dmanu :)

Juste une question pourquoi les autres émulateurs CPC ne prennent pas autant de ressources CPU que le tiens ?! N'y a-t-il pas un moyen de contourner cet obstacle ?!

Salutations !
Image
Dmanu78
Messages : 268
Inscription : 20 juin 2020 14:28
Localisation : Yvelines

Re: [EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Message par Dmanu78 »

Hello Sebiohazard :)

Je crois que tout est résumé dans cet article que l'on m'a communiqué dans un autre forum :
https://arstechnica.com/gaming/2011/08/ ... -emulator/
https://mag.mo5.com/actu/177870/chroniq ... puissance/ (en français)
Bon, l'article aborde l'émulation de la SNES mais l'esprit est le même. En résumé, plus on veut faire une émulation précise, plus il faut de la ressource CPU.

Mon émulateur est gourmand en ressource car il est codé en T-States là où la plupart des émulateurs CPC sont codés en "NOP". En résumé, pour exécuter une instruction z80 basique d'une durée de 1 NOP il suffit de faire un seul appel à l'instruction en codage "NOP". En codage "T-states", pour le même résultat, je fais 8 appels à l'instruction. Le gain de ressource est donc évident en codage "NOP".
Dans 95% des cas, un utilisateur ne verra aucune différence entre un codage en "NOP" et un codage T-states si ce n'est que le 2em est plus gourmand.

La différence commencera à se voir dans des situations extrêmes dans lesquels des timings d'une grande justesse, inférieure à la microseconde, sont requis. On retrouve ces cas dans les démos les plus techniques bien sûrs, mais pas uniquement.

Le logiciel Shaker qu'a écrit Longshot justement exploite jusqu'à l’extrême les possibilités techniques d'un CPC à travers différents tests, que l'on peut qualifier d'ACID TEST.
J'espère ne pas dire de bêtises mais je crois qu'actuellement aucun des émulateurs CPC codées en NOP ne passent le premier test de Shaker. Certains diront que ce test reste théorique et ne sert à rien en pratique mais bon, tout dépend au final de la finalité que l'on veut donner à l'émulateur.

Si c'est pour simplement jouer, un émulateur codé en "NOP", peu gourmand en ressource suffira largement. Si l'émulateur doit servir à faire des choses plus sérieuses, comme du développement de démos sur CPC, il vaut mieux avoir la plus grande justesse possible et dans ce cas le codage en T-states trouve son sens.

Maintenant, il est certain que je pourrai à terme optimiser mon code pour limiter la casse de performance. Si j'arrive à concilier précision de l'émulateur et gourmandise des ressources CPU. Ce sera parfait. ;)
Dernière modification par Dmanu78 le 02 mai 2022 00:20, modifié 1 fois.
tjjq44
Messages : 220
Inscription : 26 oct. 2016 13:40

Re: [EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

Message par tjjq44 »

Dmanu78 a écrit : 11 janv. 2022 01:20 Hello Sebiohazard :)

Je crois que tout est résumé dans cet article que l'on m'a communiqué dans un autre forum :
https://arstechnica.com/gaming/2011/08/ ... -emulator/

Bon, l'article aborde l'émulation de la SNES mais l'esprit est le même. En résumé, plus on veut faire une émulation précise, plus il faut de la ressource CPU.

Mon émulateur est gourmand en ressource car il est codé en T-States là où la plupart des émulateurs CPC sont codés en "NOP". En résumé, pour exécuter une instruction z80 basique d'une durée de 1 NOP il suffit de faire un seul appel à l'instruction en codage "NOP". En codage "T-states", pour le même résultat, je fais 8 appels à l'instruction. Le gain de ressource est donc évident en codage "NOP".
Dans 95% des cas, un utilisateur ne verra aucune différence entre un codage en "NOP" et un codage T-states si ce n'est que le 2em est plus gourmand.

La différence commencera à se voir dans des situations extrêmes dans lesquels des timings d'une grande justesse, inférieure à la microseconde, sont requis. On retrouve ces cas dans les démos les plus techniques bien sûrs, mais pas uniquement.

Le logiciel Shaker qu'a écrit Longshot justement exploite jusqu'à l’extrême les possibilités techniques d'un CPC à travers différents tests, que l'on peut qualifier d'ACID TEST.
J'espère ne pas dire de bêtises mais je crois qu'actuellement aucun des émulateurs CPC codées en NOP ne passent le premier test de Shaker. Certains diront que ce test reste théorique et ne sert à rien en pratique mais bon, tout dépend au final de la finalité que l'on veut donner à l'émulateur.

Si c'est pour simplement jouer, un émulateur codé en "NOP", peu gourmand en ressource suffira largement. Si l'émulateur doit servir à faire des choses plus sérieuses, comme du développement de démos sur CPC, il vaut mieux avoir la plus grande justesse possible et dans ce cas le codage en T-states trouve son sens.

Maintenant, il est certain que je pourrai à terme optimiser mon code pour limiter la casse de performance. Si j'arrive à concilier précision de l'émulateur et gourmandise des ressources CPU. Ce sera parfait. ;)
Je suis loin en général de cautionner le "high level emulation" mais vu que c'est pour la "bonne" cause... Juste respect!
Répondre