[Exelvision] DCEXEL 2012

[jester]

2 bugs majeurs identifiés dans dcexel 2012, régression depuis version 2010:
- la répétition du clavier entraine des à coups dans l'émulation: accélération, ralentissement, blocage, reprise. Impossible de tester un jeu en développement, les déplacements/animations crapotent, gameplay injouable/intestable. Même observation dans Wizord aussi (ou toute autres application), on voit nettement le vaisseau contrôlé faire des bonds. Idem sous Exelbasic en maintenant une touche, ça saccade (sans parler des touches à renfoncer, blocage, utiliser le clavier devient une prouesse en édition). Aucun soucis dés qu'aucune touche n'est enfoncée.
- La gestion du retour VBL dysfonctionne: il ralentie énormément la machine lorsqu'on le teste pour gérer un affichage, par exemple basculement entre deux buffers (double buffering)... plus de 10 fois plus lent que sans VBL (???)

Ces problèmes n'apparaissent pas sur vrai Exl100: répétition de touche sans impact sur la vitesse et aucune saccade, peu ou pas de blocage de touches, VBL marche normalement en imposant la fréquence de balayage sur l’affichage/animation.
Le problème de la répétition de touche n'apparait pas dans dcexel 2010 (version 13102010 par exemple), Bug VBL toujours présent (mais moins prioritaire).

A noter aussi une régression sur le réalisme dans l'affichage: sans contrôle VBL on peut avoir des cassures de l'image pendant les redraws... on l'observe sur Exl100 et sur dcexel 2010, mais plus sur dcexel2012 qui conserve une image parfaite ou presque dans tous les cas... très gênant dés lors qu'on désire mettre au point des moteur de jeux/démos, la encore le teste sur machine réelle devient vite rédhibitoire.

Imaginons q'une petite équipe développe un jeu d'action/platforme pour Exl100 et pas un éternel jeu d'aventure à deux de tension... et bien ils pourraient(voir sont) très embêtés. Le Pb de gestion du clavier est une régression majeure qui impacte toutes les applications. Retour à la version 2010, je ne me souviens plus les correctifs internes depuis qui pourraient faire apparaitre de faux bugs (pas les améliorations grand public) ?

[Daniel]

Dommage qu'on ne soit plus en 2012, car j'aurais probablement trouvé et corrigé ces problèmes. Six ans plus tard c'est beaucoup plus difficile : j'ai tout oublié du fonctionnement des ordinateurs Exelvision et je n'ai pas assez de temps libre pour m'y remettre.

Aujourd'hui, avec tout ce que l'on connaît (et qu'on ignorait à l'époque, en particulier la ROM du 7041 et le fonctionnement du 3556) la création d'un nouvel émulateur serait plus facile. C'est un appel aux programmeurs

[jester]

Mince je me suis emballé, la version 2010 ne marche pas mieux.
Du coup, je pense d'avantage à une évolution de l'archi windows / processeurs qui fait bugger une partie de ton code lié à la temporisation ou une librairie que tu utilisais et qui n'est plus 100% compatible aujourd'hui (?)
Car le problème est plus ou moins perceptible selon le sens du vent... et dramatique sur mon core i7 W10.
Je pense qu'on aurait identifié ce soucis bien avant si il avait été causé à l'origine par ton émulation.
A l'époque de mes démos et celles de Philippe, je n'avais pas identifié ces problèmes... ou bien ils étaient insignifiants par rapport à maintenant.

la création d'un nouvel émulateur serait plus facile. C'est un appel aux programmeurs

Tu sais bien que c'est impossible. Avoir un émulateur complet et fonctionnel, orienté "homebrew", était déjà un miracle pour cette machine quasi inconnue. Et même les mises à jour d'émulateur pour les machines emblématiques ne sont plus légions de nos jours.

[Silou78]

Bonjour jester,
Si le souci vient d'une incompatibilité avec Win10, as-tu essayé de lancer dcexel 2012 en mode compatibilité Win7 voire WinXP (clic-droit sur l'exe de l'émulateur, propriétés, onglet compatibilité, cocher Win7 ou XP) ?

[Daniel]

Tous mes émulateurs Windows utilisent uniquement l'API Win32 et DirectDraw. Je n'ai encore jamais rencontré d'incompatibilité avec Windows 10. Ce n'est pas impossible, mais peu probable. Au vu des symptômes décrits le problème doit être très subtil.

Des options de l'émulateur peuvent avoir une influence sur les anomalies constatées, du genre "exeldrums" (dans les périphériques) ou "accélération matérielle" (dans les paramètres). Côté système l'accélération matérielle de l'affichage est nécessaire, mais je crois qu'elle est toujours active par défaut dans un système Windows 10. Dans une moindre mesure le système audio (carte + driver) peut avoir aussi un rôle car la fréquence du processeur émulé est synchronisée avec l'horloge de la carte son.

[jester]

J'ai essayé, tout de suite, différents paramètres de l'émulateur.
Idem, j'ai testé la compatibilité W7 (sans conviction).

Les version 2012 et 2011 sont très sensibles à ce problème et les à coups en cas de répétitions de touches sont terribles.
Elles sont plus nuancées sur la version 2010 que j'ai.

Reste que d'un jour à l'autre (ou d'un démarrage de l'ordi à l'autre), le Pb peut être très léger (voir insignifiant) à terrible (inutilisable).
Je n'ai aucune explication car cela apparait quelque soit la machine et l'OS (même Philippe l'a identifié).
Par contre j'ai noté que lorsque ça marche bien, cela a tendance à continuer un moment: l'inverse est vrai aussi.

ça ressemble à une base de timing/tempo qui merdouille selon le sens du vent.
Je me souviens bien qu'il a toujours existé des Pbs de crash lors de lecture de sample LPC, et de blocage de touche sous dcexel. Mais je n'avais jamais identifié avant maintenant ce genre de crapotements de l'émulation lors du maintien enfoncé d'une touche.
Le Pb du VBL trop lent se solutionne en accélérant le CPU à 5Mhz (le double), ce n'est pas parfait mais ça permet de tester à la louche le comportement.

[6502man]

En faisant quelques test on a pu constaté avec Jester effectivement un problème lors de la répétition de touches du clavier sous DCexel en même temps je me demande si Windows n'y est pas pour quelque chose, est-ce que ce phénomène n'est pas existant aussi sur d'autres émulateurs (apllication Win32) sous Win10

[jester]

Pour affiner, le problème de crapotement/répétition de touche est faible (voir inexistant) sur ma machine de bureau sous W7... quasi imperceptible sur la version 2010 (vieille archi core i7, support X58, 3,3Ghz, 16Go RAM)... d'ailleurs le coeur de cette config date aussi de 2010!
Sur mon notebook W10, corei7 5600U 2,6Ghz, 16Go RAM, c'est un peu le festival: de parfois peu perceptible on passe vite aux à coups terribles.

Pb d'économie d'énergie plus prononcée sur le notebook ?

Mais comme c'est assez aléatoire, difficile de tirer des conclusions.

[6502man]

Donc ca pourrais bien venir de la relation entre l'appli Win32 et W10 !

[nicolho]

En vous lisant, vu les variations selon les processeurs, ça m'a fait penser aux correctifs pour Spectre et Meltdown. Comme ces failles reposent sur une mesure précise des temps d’exécution du CPU, une des tactiques pour les rendre inopérants consiste à rendre quelque peu imprécis les timers à disposition.

Enfin ça coûte rien de voir si ces patchs auraient une influence sur les dysfonctionnements constatés, en essayant de les désactiver momentanément au niveau de Windows grâce à l'utilitaire InSpectre : https://www.grc.com/inspectre.htm (il modifie des clés du registre et il faut rebooter pour que ce soit pris en compte). Par contre pas sûr que ça les désactive s'il a été procédé à une mise à jour du microcode.

[jester]

C'est une bonne piste les correctifs Spectre&Co... j'y avais pensé mais cela me semblait un peu trop extrême par rapport au problème.
Et ma machine de bureau ne dispose assurément pas de modification du microcode (première version de core i7), le notebook possède tous les niveaux de correction (OS + microcode).
Si on arrive à isoler le problème, cela sera déjà une belle avancée.

J'ai l'impression qu'il faudra bientôt une plateforme spécifique pour faire tourner les émulateurs eux-mêmes

[nicolho]

Oui, c'est juste une supposition mais comme je disais, ça coûte rien d'essayer l'utilitaire que j'ai indiqué, ça prend moins d'une minute pour le charger (126Ko), cliquer sur ses deux (seuls) boutons (un pour désactiver le patch Spectre, l'autre pour Meltdown), puis faire un reboot pour tester DCExel (mais tu es peut-être pas chez toi pour essayer...)

[jester]

Je n'ai pas constaté de différences avec ou sans activation des patchs Spectre&Co... ça crapote par moment !
Sous W7, machine de bureau, c'est quasi parfait donc je n'ai pas testé...

Philippe, sur quelle config observes-tu les à coups dans l'émulation ?

[6502man]

Sur CPU I7-7820 / RAM 15 Go / GTX 1060 / Win10 idem au bureau I7 (plus ancien) / RAM 12Go / Win10 pro

[jester]

Il s'agit de notebook ou station de bureau ?