[EMULATION AMSTRAD CPC] AMSpiriT - work in Progress

[Dmanu78]

oui tu as parfaitement résumé le problème.
En émulant le fonctionnement du moniteur CRT, j'essaye de maintenir une compatibilité minimale avec les "vieilles démos" qui trituraient pas mal le moniteur pour donner des effets de vagues hard notamment.
Maintenant le problème c'est que les moniteurs sont assez fragiles et tiennent mal dans le temps. Désormais, nos antiques CPC sont de plus en plus branchés sur un écran LCD via un adaptateur HDMI et se sera de plus en plus le cas à l'avenir...


Ce genre d'effet que "j'émule" est un pur effet CTM. Sur un écran LCD, il n'y a pas du tout le même rendu..

Je me demande si je ne devrais pas mettre une option supplémentaire permettant d'émuler ou non le comportement du CTM ? La question reste ouverte..

[TotO]

Exactement, c'est un peut le fond de ma remarque. Une option "compensation CTM" serait plutôt juste pour l'utilisateur.

[breiztiger]

cool un nouvel emu cpc ...

par contre les fonctions debug sont grisees dans la barre du haut, comment peut on les activer ?

[breiztiger]

bon ben c'est pas encore parfait

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

ne fonctionne pas sur amspirit

[Longshot]

ne fonctionne pas sur amspirit

C'est inexact.
C'est sans doute une démo ingrate, mais sur le vrai hardware, elle plante sur CRTC 1 et elle fonctionne sur les CRTC 0 et 2.
Amspirit fait la même chose.

[breiztiger]

t'es sur ? parce qu'elle fonctionne tres bien sur mon crtc1

et sous amspirit reset !!!

EDIT : sur cpcrulez c'est note all crtc

[Longshot]

t'es sur ? parce qu'elle fonctionne tres bien sur mon crtc1

Oui, je suis certain.

Cette démo est (dé)cryptée « classiquement » avec des XOR avec la valeur du registre R.
Le registre R évolue selon le nombre d'octets d'instructions lu par le Z80A.

Code : Tout sélectionner

#8438
	          ei				; interruptions autorisées
		  ld b,#f5			; attente de vsync
wait_vsync			  
		  in a,(c)
		  rra
		  jp nc,wait_vsync
                  halt			; et interruption pour caler R
                  ld a,#da                  ; R initialisé pour le decodage
                  ld r,a
                  ld hl,#140		; debut du code a decrypter
                  ld de,#81d2             ; longueur du code a decrypter
decode
	          ld a,r			; r=r+2 Lecture de R
	          xor (hl)			; r=r+1 Decodage
	          ld (hl),a			; r=r+1 Remise en memoire
	          inc hl			; r=r+1
	          dec de                    ; r=r+1
	          ld a,d                     ; r=r+1
	          or e                        ; r=r+1
	          jp nz,decode          ; r=r+1

Cependant, les interruptions sont actives.
Avant le décodage, R est calé à partir d'un HALT.
Dès qu'une interruption survient dans cette boucle, le registre R est incrémenté par l'appel et le code de l'interruption.
Tout irait bien si les interruptions étaient très précises et tombaient toujours au même endroit.

Mais ce n'est pas toujours le cas, et notamment sur le CRTC 1.
Dans ce cas, si l'interruption survient avant ou après le LD A,R, la valeur de R ne sera pas la même pour décoder l'octet.
Et par voie de conséquence, le décodage se passe bien sur certains CRTC 1 et moins bien sur d'autres.
Sur mon CRTC 1 numéro 1, la démo fait un RESET.
Sur mon CRTC 1 numéro 2, la démo démarre mais tous les gfx sont totalement corrompus.
Aucun problème sur CRTC 0 et 2.

Tu trouveras l’explication détaillée sur ce sujet au chapitre 26.7.2 (p 275) du compendium 1.5.

En gros, cela tient à la précision du CRTC à signaler sa fin de HSYNC au GATE ARRAY pour que ce dernier demande une interruption au Z80A.

[hlide]

Pour qu'un tel code fonctionne, il faudrait aussi que la seule source d'interruption soit le VSYNC. Si on ajoute sur le bus d'expansion une carte qui fait mumuse avec /INT ou /NMI (et oui, il faut pas l'oublier celui-là quand il est utilisé) pour le son par exemple, c'est facteur de perturbation.

[breiztiger]

Ben je viens de vérifier et bien le grand longshot se fourvoie

mon cpc a bien un UM6845R donc crtc1

Et cette démo fonctionne bien sur celui ci

[hlide]

Et tu ne sais pas lire :

Et par voie de conséquence, le décodage se passe bien sur certains CRTC 1 et moins bien sur d'autres.

Ce n'est pas parce que ça fonctionne bien sur ta machine qu'il faut le généraliser à toutes les machines avec leur variante de CRTC1.

[breiztiger]

et comme par hasard j'ai un crtc1 qui fonctionne

et donc normal que amspirit reset sur les deux types de crtc1 ? pour moi c'est qu'il y a un soucis

m'enfin encore une question sans reponse et qui ne fait pas avance le dev des emus

[Longshot]

encore une question sans reponse

La question n'est pas sans réponse.
Je répète, mais tu trouveras l’explication détaillée sur ce sujet au chapitre 26.7.2 (p 275) du compendium 1.5.
(http://logonsystem.fr/down/ACCC1.5-FR.pdf)

C'est une question de niveau de tolérance du circuit (sa plage de délais est indiquée dans le datasheet).
Le CRTC est "cadencé" à 1Mhz, et le GATE ARRAY 16 fois plus vite.
Tous les délais "internes" du CRTC sont loin d'être garantis à 16Mhz.

C'est un peu comme les processeurs intel qui étaient garantis jusqu'à une fréquence donnée, mais leur overclock dépendait des séries.

Ce sujet a été analysé sur mon ancienne protection de la démo Revolog.
Le problème des interruptions manquées se présente principalement sur CRTC 1.
Pour l'émulation CPC, DManu a pris le cas que nous avons rencontré le plus souvent sur ce CRTC.

Il est sans doute possible de prévoir un ajustement de 1 à 3/16eme dans l'émulateur pour fixer cette tolérance, puisqu'il tourne à 16Mhz.
Mais c'est surtout à DManu de donner son avis je pense.

et comme par hasard j'ai un crtc1 qui fonctionne

Les autres CRTC 1 font ce qu'on attend d'eux avec leur niveau de tolérance. Ni plus ni moins.
A la limite, tu peux dire que tu "as la chance" que la démo "Equalizor" se décrypte bien, alors qu'elle vautre sur d'autres CRTC 1.

[Dmanu78]

Je me souviens très bien de ce sujet, nous avons longuement échangé avec Longshot dessus à l’époque. Cela fait même l’objet d’un test shaker spécifique dans lequel nous avons effectivement découvert que le comportement du crtc 1 différait des autres dans certains cas. A titre perso j’ai 2 CPC crtc 1 : sur l’un le test foire, sur l’autre ça passe. Nous avons interrogé plusieurs possesseurs de CPC ayant un crtc 1 et à 80% des retours, le test foirait. A défaut, j’ai donc programmé Amspirit pour reproduire le comportement de la majorité des crtc 1. D’ailleurs chose amusante, il me semble que même sur un CPC crtc0 ayant un peu monté en température, le test foire aléatoirement…bref, ce type de test est instable même sur un vrai CPC ce qui explique que l’on ne se soit pas attardé dessus. On atteint la limite de précision hard du CPC.
J’ai fait quelques simulations et il suffit que le crtc retarde la fin du signal hsync de 1 à 2/16Mhz par rapport aux crtc 0/2 pour que le test foire.

Maintenant je pourrais mettre une option pour que le crtc 1 se comporte comme les crtc 0 ou le 2 pour répondre à toutes les situations… ça ne présente pas forcément beaucoup d’intérêt en vérité. Je ne connais que 2 démos utilisant cette technique mais ça peut se faire s’il y a un besoin.

[breiztiger]

Je pense que l’on est plutôt dans le vieillissement de nos chers cpc

Certaines valeurs ont « déviés » de leurs valeurs d’origines

Je vais essayer de remettre en marche tout mes 6128 et voir les crtc1 qui ne fonctionnent pas

Ps : pas eu de réponse sur le debug intégré à amspirit et serait il possible d’y intégrer le drag’n drop stp

[Longshot]

Je pense que l’on est plutôt dans le vieillissement de nos chers cpc

Cet écart sur les interruptions existait déjà à la fin des années 80.
Sur des machines multi-CRTC, on le remarque principalement avec le CRTC 1 (alors que les autres CRTC sur la même machine ne sont pas affectés).

On a toutefois noté que cela pouvait survenir sur CRTC 0 et 2 dans certaines situations.
En 1989, la protection de Revolog plantait sur mon CRTC 0 lorsque mon CPC était allumé depuis plus de 10 mn.

Je pense que la tolérance du circuit doit être affectée par sa consommation électrique, l'alimentation du CPC et la chaleur.
C'est déjà beau qu'on ait une précision relative à 0.0625 µsec et que les instructions courtes ne soient pas affectées.

On est preneur du résultat avec tes différents CRTC (y compris les 0 et 2 si il y a).