[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
OlivierZ
Messages : 16
Inscription : 11 déc. 2020 23:30
Localisation : Courbevoie

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

Message par OlivierZ »

Bonjour,

En analysant le fichier image de sauvegarde (autosave.img) de l'émulateur TEO (1.8.4) je me suis plongé dans les sources (merci de les avoir rendu disponibles !) et je pense avoir trouvé un bug. La fonction d'écriture du chunk diskctrl_Loader déclare écrire 128 bytes mais en écrit 80 (2+26+26+26) car NBDRIVE est à 4:

Code : Tout sélectionner

static void diskctrl_Saver(int chunk_id)
{
    int drive;

    fwrite_int16 (128);

    fwrite_int16  (dkcurr);

    for (drive=0; drive<NBDRIVE; drive++)
    {
        /* controller registers */
        if ((drive&3) == 0)
        {
            fwrite_int8  (disk[drive].dkc->rr0);
            fwrite_int8  (disk[drive].dkc->rr1);
            fwrite_int8  (disk[drive].dkc->rr2);
            fwrite_int8  (disk[drive].dkc->rr3);
            fwrite_int8  (disk[drive].dkc->rr4);
            fwrite_int8  (disk[drive].dkc->rr5);
            fwrite_int8  (disk[drive].dkc->rr6);
            fwrite_int8  (disk[drive].dkc->rr7);
            fwrite_int8  (disk[drive].dkc->rr8);
            fwrite_int8  (disk[drive].dkc->rr9);
            fwrite_int8  (disk[drive].dkc->wr0);
            fwrite_int8  (disk[drive].dkc->wr1);
            fwrite_int8  (disk[drive].dkc->wr2);
            fwrite_int8  (disk[drive].dkc->wr3);
            fwrite_int8  (disk[drive].dkc->wr4);
            fwrite_int8  (disk[drive].dkc->wr5);
            fwrite_int8  (disk[drive].dkc->wr6);
            fwrite_int8  (disk[drive].dkc->wr7);
            fwrite_int8  (disk[drive].dkc->wr8);
            fwrite_int8  (disk[drive].dkc->wr9);
            fwrite_int8  (disk[drive].dkc->crc);
            fwrite_int8  (disk[drive].dkc->write_door);
            fwrite_int8  (disk[drive].dkc->process);
            fwrite_int8  (disk[drive].dkc->process_cpt);
            fwrite_int16 (disk[drive].dkc->auto_count);
        }

        /* drive registers */
        if ((drive&1) == 0)
        {
            fwrite_int16 (disk[drive].drv->sector);
            fwrite_int16 (disk[drive].drv->track.curr);
            fwrite_int16 (disk[drive].drv->track.last);
            fwrite_int16 (disk[drive].drv->pos.curr);
            fwrite_int16 (disk[drive].drv->pos.last);
            fwrite_int64 (disk[drive].drv->motor_start);
            fwrite_int64 (disk[drive].drv->motor_stop);
        }
    }
    (void) chunk_id;
}
Voici un Dump du fichier sauvegarde.img :

Code : Tout sélectionner

        54 45 4F 20 49 4D 41 47 45 20 46 49 4C 45 20 46   TEO IMAGE FILE FORMAT 
        4F 52 4D 41 54 20 

        0201    format_version
        0301    TO8D
        00 00 00 00 00 00  Reserved
        
        01 00   mc6809_Loader
        00 1F 
        D0 E7 AD 34 00 08 00 03 00 02 62 DA EE A0 00 00 
        00 00 05 77 6E 02 00 00 00 00 05 78 D5 66 01 
        
        02 00   mc6846_Loader
        00 11 
        81 B1 3D BC 3D 46 30 D3 08 00 00 00 00 05 78 D5 
        66 
        
        03 00   mc6821_Loader
        00 0A 
        3C FE 00 00 FE 3C 0F 06 F6 FF 
        
        03 10  mc6821_Loader
        00 0A 
        DF 00 00 FF 00 C4 3F C0 C0 3F 
        
        04 00   modepage_Loader
        00 0C 
        00 00 00 44 00 00 02 00 00 00 00 00 
        
        05 00  palchip_Loader = 16 couleurs 
        00 20 
        00 E0 1B E2 20 E0 1B E0 22 E5 24 E1 6F E1 FF EF 
        77 E7 15 E1 31 E1 9F E4 41 E8 3E E1 94 EF FE E4 
        
        06 00  diskctrl_Loader
        00 80    => 80 bytes pas 128 !!
        00 00  current drive
        80 20 00 4E FF 00 00 00 00 00 00 20 40 00 00 0B 
        1B 9F 00 00 0B 00 00 00 00 00 00 00 00 00 FF FF 
        09 DA 18 44 00 00 00 00 00 D4 86 69 00 00 00 00 
        03 52 2E 33 00 00 00 00 FF FF 00 00 00 00 00 00 
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 
        
        07 00  mempager_Loader
        00 0A 
        00 00 00 00 00 01 02 02 02 01 
        
        09 00  mb_Loader
        00 09 
        00 00 00 00 05 77 6E 00 01 
        
        08 00=bank   membank_Loader
        3F 02 => data_size = 3F00
        00 80  begin 
Je serai preneur d'une version de TEO où il serait possible de sauvegarder l'état de l'émulateur via le menu (en choisissant le nom du fichier de sauvegarde, dont le format serait identique au fichier autosave.img) et en pouvant recharger un fichier de sauvegarde également depuis le menu (ce qui provoquerait un cold-reset). Cela permettrait de sauvegarder une partie d'un jeu lorsque cela n'a pas été prévue dans le soft. Aujourd'hui, il faut fermer l'émulateur et penser à sauvegarder le fichier autosave.img à la mano.

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 »

En attendant la correction des sources et la mise à disposition d'une nouvelle version, il vous est possible de patcher directement l'exécutable Windows à deux endroits :

Remplacer les 0x80 par des 0x50 aux offsets 0xCAA4 et 0xD240 du fichier teow.exe (version 1.8.4 de 285696 octets).

Cela correspond aux fonctions de lecture/écriture du fichier autosave.img :

Code : Tout sélectionner

.text:0040D68C                         
.text:0040D68C                         loc_40D68C:                             ; CODE XREF: sub_40D660+241j
.text:0040D68C F7 C6 01 00 00 00                       test    esi, 1
.text:0040D692 74 3C                                   jz      short loc_40D6D0
.text:0040D694                         
.text:0040D694                         loc_40D694:                             ; CODE XREF: sub_40D660+D3j
.text:0040D694 46                                      inc     esi
.text:0040D695 83 C3 48                                add     ebx, 48h
.text:0040D698 83 FE 03                                cmp     esi, 3
.text:0040D69B 7E E3                                   jle     short loc_40D680
.text:0040D69D E8 BE A1 FF FF                          call    sub_407860
.text:0040D6A2 81 FF 80 00 00 00                       cmp     edi, 80h
.text:0040D6A8 7F 08                                   jg      short loc_40D6B2
.text:0040D6AA                         
.text:0040D6AA                         loc_40D6AA:                             ; CODE XREF: sub_40D660+68j
.text:0040D6AA 8D 65 F4                                lea     esp, [ebp-0Ch]
.text:0040D6AD 5B                                      pop     ebx
.text:0040D6AE 5E                                      pop     esi
.text:0040D6AF 5F                                      pop     edi
.text:0040D6B0 5D                                      pop     ebp
.text:0040D6B1 C3                                      retn
et

Code : Tout sélectionner

.text:0040DE30 55                                      push    ebp
.text:0040DE31 89 E5                                   mov     ebp, esp
.text:0040DE33 56                                      push    esi
.text:0040DE34 53                                      push    ebx
.text:0040DE35 31 F6                                   xor     esi, esi
.text:0040DE37 83 EC 0C                                sub     esp, 0Ch
.text:0040DE3A BB 18 48 43 00                          mov     ebx, offset dword_434818
.text:0040DE3F 68 80 00 00 00                          push    80h
.text:0040DE44 E8 47 F3 FF FF                          call    sub_40D190
.text:0040DE49 58                                      pop     eax
.text:0040DE4A A1 00 D5 42 00                          mov     eax, dword_42D500
.text:0040DE4F 50                                      push    eax
.text:0040DE50 E8 3B F3 FF FF                          call    sub_40D190
.text:0040DE55 83 C4 10                                add     esp, 10h
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 »

Effectivement il semble y avoir une incohérence entre sauvegarde et relecture du dump du controleur disque (ce n'est peut être pas la seule imprécision de la sauvegarde de l'état du contrôleur disque... et de façon surprenante... ca semble fonctionner sur plateforme linux, la RAM est bien relue sans décalage). => je vais regarder ce qui se passe.

Pour la lecture/sauvegarde de point de reprise il faut voir l'endroit le plus intéressant pour la fonction. Au niveau du debugger integré ca me semble pas mal comme endroit pour ne pas surcharger le menu principal. Perso je n'ai jamais trop utilisé la sauvegarde d'état parceque je relance l'ému assez souvent, j'imagine que pour certains jeux ce serait utile pour garder une progression.
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 : 13 déc. 2020 15:58 Pour la lecture/sauvegarde de point de reprise il faut voir l'endroit le plus intéressant pour la fonction. Au niveau du debugger integré ca me semble pas mal comme endroit pour ne pas surcharger le menu principal. Perso je n'ai jamais trop utilisé la sauvegarde d'état parceque je relance l'ému assez souvent, j'imagine que pour certains jeux ce serait utile pour garder une progression.
J'aurai bien vu deux boutons 'Charger' et 'Sauvegarder' à côté de 'A Propos' et 'Quitter'.

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 »

une petite vérif plus tard.
En fait la double erreur s’annule... donc le code d'origine marche quand même (c'est le cas sur linux)
A la sauvegarde la taille indiquée est 128 mais seuls 80octets sont sauvegardés
A la lecture on va lire 80 octets... on peut s'attendre à une erreur et un décalage dans diskctrl_Loader() au moment du

Code : Tout sélectionner

FILL_GAP    (128, chunk_size);
Mais en fait non, car chunk_size est (faussement) à 128 et donc le code est sans effet.

Donc oui c'est une erreur à corriger (le fichier image ne respecte pas sa structure) mais ca ne devrait pas bloquer le fonctionnement.

Après le format de sauvegarde des banques mémoire est un peu complexe (il tient compte de l'état par défaut de la RAM post test mémoire et ne sauvegarde que ce qui a changé). C'est plutôt efficace car effectivement une machine juste démarrée a une sauvegarde de taille très faible (environ 50k) mais pour bosser sur le format image ca ne facilite pas la tâche.
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 : 13 déc. 2020 22:48 Donc oui c'est une erreur à corriger (le fichier image ne respecte pas sa structure) mais ca ne devrait pas bloquer le fonctionnement.
Oui en effet les deux erreurs ont tendance à s'annuler mais si le format img de sauvegarde de l'état pouvait être étendu à un snapshot 'à la demande', il serait utile de corriger le problème de chunk_size pour s'assurer d'une interopérabilité avec les outils externes. Je me sert notamment des snapshots mémoires de Teo comme entrée d'un logiciel de Reverse Engineering afin d'analyser certains softs tournant sur la gamme Thomson.
gilles a écrit : 13 déc. 2020 22:48 Après le format de sauvegarde des banques mémoire est un peu complexe (il tient compte de l'état par défaut de la RAM post test mémoire et ne sauvegarde que ce qui a changé). C'est plutôt efficace car effectivement une machine juste démarrée a une sauvegarde de taille très faible (environ 50k) mais pour bosser sur le format image ca ne facilite pas la tâche.
Oui j'ai pu extraire les données de 32 banques mémoires et j'ai pu noter l'utilisation du Zebra mémoire 0x00 / 0xFF. Je me sert conjointement des doc techniques (Manuel Technique des TO8, TO9 et TO9+) et du code source de Teo pour appréhender l'architecture MO-TO (qui est un peu ... particulière).

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 »

Bonjour,

Je regarde la mémoire d'un TO8D via les debugger des deux émulateurs TEO et DCMOTO (dernière version pour les 2), et j'ai des différences.

Les zones de mémoire non initialisées sont remplies de bandes de 0x00 / 0xFF :

0x00,0x00,0x00...
0xFF,0xFF,0xFF...
0x00,0x00,0x00...
0xFF,0xFF,0xFF...

Pour TEO, chaque zone de 0x00 ou 0xFF fait 256 bytes alors que pour DCMOTO ces bandes ne font que 128 bytes.

Savez vous quelle est la vraie représentation ? La longueur des bandes dépend t'elle du modèle d'ordinateur (TO-MO) émulé ?

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 ne faut pas faire confiance à dcmoto, je n'ai jamais vérifié. J'ai programmé initialement pour le MO5 (ou peut-être le MO6, je ne me souviens plus) et j'ai appliqué la même formule aux autres ordinateurs. Normalement l'initialisation de la RAM ne devrait avoir aucune influence sur les programmes, mais il y a une exception : Marche à l'Ombre version MO. Le programme a un bug. Si la mémoire est initialisée à zéro, le programme se plante. Par contre, avec l'alternance de $00 et $FF il retombe (par miracle) sur des instructions valides et fonctionne.

Initialiser correctement la RAM est une question intéressante pour les pinailleurs (comme moi). Si on peut recenser les règles pour chaque machine je corrigerai. Je crois qu'aucune documentation ne donne ces règles, il va falloir les retrouver.
Daniel
L'obstacle augmente mon ardeur.
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 »

Il faudrait que je regarde mais je ne pense pas qu'il s'agisse de mémoire non initialisée. Plutôt de l'état de la mémoire laissé par le test mémoire de la ROM.
Sur la machine réelle la ram non initialisée a une valeur qui dependra du comportement de chaque circuit de RAM et il ne sera pas toujours reproductible d'une machine à une autre (les valeurs vont tout de même se ressembler souvent, c'est pour cela qu'on retrouve souvent les mêmes patterns à l'écran lors d'un démarrage à froid sur les thomson et sur d'autres 8 ou 16bits).
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 »

Si l'un de vous deux est possesseur d'un TO8D (qui semble être à la croisé des modèles récents) en état de marche, vous serait t'il possible de démarrer la machine et, depuis le basic, taper les 10 lignes de basic permettant de dumper les valeurs des Zones mémoires Système ($6000) et Data ($A000) afin qu'on puisse savoir si ces entrelacement de 0x00 et de 0xFF sont présents et quel sont leurs longueurs et alignement ?

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 »

La valeur des bits à l'initialisation dépend du type de DRAM. Dans le TO8 et le TO8D ce sont des 41256.
Je viens de vérifier à l'instant avec un TO8, à l'initialisation la RAM contient des séquences de 128 x $00 suivis de 128 x $FF.
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 »

Merci d'avoir pris le temps de regarder.

Le code d'initalisation de Teo indique, pour chaque banc de 16 KB, un entrelacement 128 * 0x00 / 256 * 0xFF / 256 * 0x00 / 256 * 0xFF... 128 * 0x00 :

Code : Tout sélectionner

static void memory_hard_reset(void)
{
    int bank;
    int addr;

    for (bank=0; bank<mem.ram.nbank; bank++)
    {
        for (addr=0; addr<mem.ram.size; addr+=512)
        {
            memset (&mem.ram.bank[bank][addr], 0x00, 128);
            memset (&mem.ram.bank[bank][addr+128], 0xff, 256);
            memset (&mem.ram.bank[bank][addr+384], 0x00, 128);
        }
    }
}
On aurait donc des blocs de 256 bytes (de 0x00 et de 0xFF), sauf aux extrémités des bancs où on aurait 128 x 0x00 au début et 128 x 0x00 à la fin.

Ca semble être différent de ce qui a été observé sur la machine.

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__ »

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

@sam: il existe des cas très rares de programmes "debuggés" où cela peut se produire. Ce type de programme ne fonctionne que si la machine a été éteinte un temps assez long.

Dans l'historique du dev de TEO ces valeurs d'initialisation ont été ajoutées par prehisto assez tardivement (je pense qu'il a observé les valeurs sur la machine réelle). Ces valeurs sont comparées à l'état courant de la banque mémoire lors de la sauvegarde du snapshot pour réduire la taille (perso j'aurai plutôt fait du RLE ici, moins spécifique). Par contre teo émule un TO8D. Je ne vois pas trop pourquoi le D serait différent du normal mais c'est possible si le gate array fait quelquechose avec la RAM pendant le reset initial (et il y a peut être des variantes de gate array) ou encore si quelque part dans la ROM du TO8 une initialisation explicite de la RAM est faite (le 8 et le 8D ont des roms légerement différentes).
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 »

Gilles a raison : la RAM est initialisée différemment entre le TO8 et le TO8D.
Il n'y a pas d'initialisation particulière de la RAM à la mise sous tension, les valeurs sont déterminées par le hardware, pas par soft.

BASIC.jpg
BASIC.jpg (36.85 Kio) Consulté 5305 fois

TO8.jpg
TO8.jpg (81.22 Kio) Consulté 5305 fois

TO8D.jpg
TO8D.jpg (69.03 Kio) Consulté 5305 fois
Daniel
L'obstacle augmente mon ardeur.
Répondre