[THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

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
gilles
Messages : 2779
Inscription : 07 août 2008 13:44
Localisation : Nantes
Contact :

Re: [THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

Message par gilles »

ce sont des valeurs qui semblent fixes et inhabituelles. Sachant que le gate array "page mode" recoit le reset je me demande si il ne se passe pas quelquechose pendant cette phase de reset (il y a forcement le refresh qui continue pendant le reset à chaud car sinon lors d'un reset prolongé le TO8 risquerait de perdre le contenu de sa ram). A regarder un jour à l'analyseur logique au niveau d'un boitier de DRAM par exemple.
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

Message par Daniel »

Une hypothèse pour expliquer la différence entre le TO8 et le TO8D : des pistes d'adresse ont peut-être été croisées entre le processeur et la RAM pour optimiser le dessin de la carte mère.

Je n'ai pas trouvé d'indication dans la datasheet des rams pour déterminer la valeur des bits à la mise sous tension. Il faudrait aussi faire des tests. Et mesurer le délai entre la mise sous-tension et le démarrage du rafraîchissement.

Mais encore une fois tout ça est du pinaillage. Les programmes ne doivent pas compter sur une configuration quelconque à la mise sous tension, c'est au programmeur d'initialiser la RAM qu'il utilise.
Daniel
L'obstacle augmente mon ardeur.
Avatar de l’utilisateur
OlivierZ
Messages : 16
Inscription : 11 déc. 2020 23:30
Localisation : Courbevoie

Re: [THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

Message par OlivierZ »

__sam__ a écrit : 21 déc. 2020 23:24 Juste une question: ca importe vraiment les motifs des ram non initialisées au reset ? Perso jamais je n'ai vu le moindre impact sur un prog bien écrit.
Ce n'est pas tant les valeurs présentes dans la RAM qui sont importantes (le programmeur a en effet intérêt à ne faire aucune hypothèse dessus, voir à nettoyer la zone avant utilisation), c'est le fait que quand je compare le Dump mémoire d'un même jeu (les 64 KB visibles du proc) des deux émulateurs (TEO et DcMoto en mode TO8D), je n'obtiens pas les mêmes valeurs... et j'essaye de comprendre pourquoi. Comme je n'arrive pas à mettre la main sur une vraie machine (TO8D), je me dois demander ici un peu d'aide.

Olivier
Avatar de l’utilisateur
gilles
Messages : 2779
Inscription : 07 août 2008 13:44
Localisation : Nantes
Contact :

Re: [THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

Message par gilles »

un dump en ram ca change tout le temps... avec les variables locales, l'état de l'écran... A la limite en positionnant un point d’arrêt processeur connu et en faisant le dump à ce moment on peut s'approcher de l'égalité.
Avatar de l’utilisateur
OlivierZ
Messages : 16
Inscription : 11 déc. 2020 23:30
Localisation : Courbevoie

Re: [THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

Message par OlivierZ »

Daniel a écrit : 22 déc. 2020 11:13 Mais encore une fois tout ça est du pinaillage. Les programmes ne doivent pas compter sur une configuration quelconque à la mise sous tension, c'est au programmeur d'initialiser la RAM qu'il utilise.
Il est quand même intéressant de connaitre précisément l'état de la mémoire avant que le programme ne l'altère car cela permet de savoir ce que le programme a modifié. En disposant d'un 'calque' composé des valeurs d'initialisation, en effectuant un delta sur les octets, on obtient immédiatement les zones qui ont bougé. C'est d'ailleurs ce que fait TEO pour savoir quoi backuper pour ses fichiers images.

Moi, de mon côté, j'ai dans mon soft une représentation graphique de la mémoire et je met en exergue les zones mémoires qui contiennent des valeurs autres que celles d'initialisation, je suis donc intéressé par avoir une représentation la plus exacte possible. Aujourd'hui les zebra de 0x00 et 0xFF sont considérés comme des valeurs alors qu'il n'y a rien.
LPDV.gif
LPDV.gif (29.91 Kio) Consulté 4693 fois
Olivier
Avatar de l’utilisateur
OlivierZ
Messages : 16
Inscription : 11 déc. 2020 23:30
Localisation : Courbevoie

Re: [THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

Message par OlivierZ »

gilles a écrit : 22 déc. 2020 12:01 un dump en ram ca change tout le temps... avec les variables locales, l'état de l'écran... A la limite en positionnant un point d’arrêt processeur connu et en faisant le dump à ce moment on peut s'approcher de l'égalité.
Je suis d'accord, mais les différences que je trouve sont assez importantes. C'est peut être lié à ma compréhension du format de sauvegarde de TEO mais quand je reconstruis les 64 KB visibles par le processeur d'un jeu qui ne bouge pas (Les passagers du Vent I), je ne suis pas raccord entre TEO et DCMOTO (je ne parle pas des registres du proc ou de quelques bytes en mémoire). Les zebras de 0x00 et 0xFF en sont un exemple parmi d'autres.

Je vais continuer à creuser le format de sauvegarde avant de te faire remonter mes observations.

Existe t'il sur TO8D un moyen hardware (genre action replay) d'obtenir la copie des 64 KB de ROM/RAM/ROM visible par le proc à un instant T. J'avais vu ça sur la plupart des micros genre Atari ST ou Apple II ?

Olivier
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

Message par __sam__ »

Ben pourquoi ne commences tu pas dans les deux émulateurs par mettre les mémoires dans le même état (tout à 0, tout à 255 ou tout à "adresse MOD 256", au choix) via un programme basic à saisir sur la console, et ensuite tu RESET à chaud et charges le jeu. Ainsi tes comparaisons entre les deux émulateurs seront bien plus simples puisque tu pars du même point de départ.
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
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

Message par Daniel »

OlivierZ a écrit : 22 déc. 2020 12:17 je met en exergue les zones mémoires qui contiennent des valeurs autres que celles d'initialisation
Quand on rencontre une zone de $00 ou une zone de $FF, il est impossible de savoir si c'est une séquence initiale ou une zone modifiée par le programme.

Et aussi ça dépend des programmes exécutés avant le chargement. Par exemple, si le programme est chargé par SDDRIVE à partir d'une carte SD, la RAM ne contient pas la même chose que s'il a été chargé avec une disquette. Avec un chargement par cassette c'est encore différent. Les variables système, les variables BASIC et les programmes de chargement écrasent les séquences initiales, il vont être pris en compte alors qu'ils ne font pas partie du programme étudié.

Quelle est la finalité de cette comparaison de toute la RAM entre les deux émulateurs ?
Daniel
L'obstacle augmente mon ardeur.
Avatar de l’utilisateur
OlivierZ
Messages : 16
Inscription : 11 déc. 2020 23:30
Localisation : Courbevoie

Re: [THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

Message par OlivierZ »

__sam__ a écrit : 22 déc. 2020 13:03 Ben pourquoi ne commences tu pas dans les deux émulateurs par mettre les mémoires dans le même état (tout à 0, tout à 255 ou tout à "adresse MOD 256", au choix) via un programme basic à saisir sur la console, et ensuite tu RESET à chaud et charges le jeu. Ainsi tes comparaisons entre les deux émulateurs seront bien plus simples puisque tu pars du même point de départ.
C'est globalement ce que je fais, et j'efface même le fichier image et le fichier Ini pour TEO pour retrouver les valeurs d'initialisation de l'émulateur.

De plus, j'ai choisi le même fichier image disque d'un jeu d'aventure qui ne bouge pas (le passager du Vent I), en se positionnant sur le premier écran de jeu (le ponton ?). La capture de 64 KB se fait différemment selon les deux émulateurs :
- Pour DCMOTO, je file dans Outils / Mise au Point, je sélectionne la plage Adresse 0000-FFFF et je sauvegarde via le bouton Save.
- Pour TEO, qui ne dispose pas dans son debugger de sauvegarde de Data, je quitte simplement le programme et j'exploite le contenu du fichier autosave.img.

Le fichier sauvegarde de TEO contient différentes informations comme la valeurs des registres du Proc, les registres de configuration mémoire, les couleurs de la palette et les bancs 16 KB dont au moins une des valeurs seraient différentes de la pattern d'initialisation. Donc en final, on se retrouve avec potentiellement les 512 KB de la ram (32*16 KB) mais jamais les 64 KB qui voyait le Proc lors de la coupure. Il faut donc reconstruire à la main ces 64 KB en y ajoutant les fichiers de Rom (Basic / Moniteur) et en sélectionnant les Pages RAM de 16 KB (Vidéo, Système, Data) en fonction de ce qui a été sélectionné par le programme.

Pour l'instant, ces deux zones mémoires (celle de DCMOTO et celle que je reconstruis depuis le fichier de sauvegarde de TEO) ne correspondent pas. C'est par exemple de cette comparaison qu'est partie la discussion sur les Zebra 0x00 et 0xFF. J'ai pour l'instant des différences sur la zone graphique sélectionnée (forme vs couleur), la page Data et la Rom Moniteur sélectionnée.

Comme c'est moi qui reconstruit ces 64 KB, j'ai bien conscience que le problème est probablement de mon côté mais il serait évidemment plus simple pour comprendre l'origine du problème de se baser sur un Dump mémoire 'sûr'.

Olivier
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

Message par __sam__ »

OlivierZ a écrit : 22 déc. 2020 14:07 C'est globalement ce que je fais, et j'efface même le fichier image et le fichier Ini pour TEO pour retrouver les valeurs d'initialisation de l'émulateur.
Ben non c'est pas pareil: cela dépends de l'émulateur. C'est pour cela que je parlais d'un état mémoire identique aux deux émulateurs parce que tu as précédemment lancé le même code d'initialisation de la RAM. Ainsi les deux machines émulées seront dans le même état de départ et la comparaison aura bien plus de sens.
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
gilles
Messages : 2779
Inscription : 07 août 2008 13:44
Localisation : Nantes
Contact :

Re: [THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

Message par gilles »

pour la sauvegarde d'état dans teo cela va arriver dans le debugger, mais je dois adapter la chaine de compilation à un truc un peu plus moderne (msys2) et cela me prend un peu de temps (bon, d'un autre côté c'est aussi une autoformation au truc pour mon taf, tout n'est pas perdu).

Il m'est déjà arrivé de faire du debug intensif avec une seconde plage mémoire qui indiquait explicitement si la mémoire avait été modifiée (et à partir de quelle adresse pour l'instruction la modifiant), mais c'était une branche expérimentale pour un émulateur, je ne sais plus lequel, peut être pour le NeXT... et on ne retrouve pas trop souvent ce genre de chose dans du code utilisateur.
Avatar de l’utilisateur
OlivierZ
Messages : 16
Inscription : 11 déc. 2020 23:30
Localisation : Courbevoie

Re: [THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

Message par OlivierZ »

Daniel a écrit : 22 déc. 2020 13:06 Quelle est la finalité de cette comparaison de toute la RAM entre les deux émulateurs ?
__sam__ a écrit : 22 déc. 2020 14:31 Ben non c'est pas pareil: cela dépends de l'émulateur. C'est pour cela que je parlais d'un état mémoire identique aux deux émulateurs parce que tu as précédemment lancé le même code d'initialisation de la RAM.
L'idée est de se rassurer sur la qualité des Dumps mémoires en vérifiant que deux émulateurs différents produisent bien la même image mémoire d'un même logiciel (à l'exception des petites différences liées au moment de la capture : Registres du Proc, VBL...). C'est pour cela que je cherche à comprendre d'où viennent les différences que je suis parfois amené à constater.

Olivier
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

Message par Daniel »

Il est illusoire de dire que les Passagers du Vent ne modifient pas la RAM quand ils sont apparemment en attente sur un écran.

Il se passe pas mal de choses en arrière plan, en particulier une boucle d'attente d'appui sur une touche et des interruptions. Il y a en permanence des appels à des routines systèmes qui font des traitements, en particulier elles changent de banque mémoire et elles modifient des valeurs en RAM, ne serait-ce que la pile système.

Il n'y a aucune chance que le dump mémoire soit identique, même avec le même émulateur, même à quelques microsecondes d'intervalle.
Daniel
L'obstacle augmente mon ardeur.
Avatar de l’utilisateur
OlivierZ
Messages : 16
Inscription : 11 déc. 2020 23:30
Localisation : Courbevoie

Re: [THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

Message par OlivierZ »

Quand je parle de différences, ce n'est pas les quelques bytes de mémoire liés à l'exécution du programme dont il est question, mais plutôt de ça :

Les passagers du Vent, sous TEO :
TEO.gif
TEO.gif (33.44 Kio) Consulté 4644 fois
Les passagers du Vent sous DCMOTO (en émulation TO8D) :
DCMOTO.gif
DCMOTO.gif (41.02 Kio) Consulté 4644 fois
D'un côté la RAM est en Page 2 alors que pour l'autre, c'est en Page 3...
Avatar de l’utilisateur
gilles
Messages : 2779
Inscription : 07 août 2008 13:44
Localisation : Nantes
Contact :

Re: [THOMSON - TEO Windows 1.8.4] Bug Report / Demande d'amélioration

Message par gilles »

ce n'est pas la bonne méthode.
Ce qu'il est possible de faire c'est de s’arrêter à l'état courant sur un émulateur, noter le PC et demander un arrêt sur ce même point d'arret sur l'autre.
Mais ca ne sera pas nécessairement le même état malgré tout. Trop de paramètres entrent en jeu. Ici on est dans des zones système en F000 et ce n'est pas un bon candidat comme point d'arret, un appel système peut survenir de n'importe où.
Un bon point d'arret peut être c'est l'entrée de la routine disque en $E004. A ce stade on a des chances d'avoir, grosso modo, le même état.
Répondre