[Thomson] SDDRIVE

[Daniel]

Le BASIC 128 est incompatible TO7, c'est écrit sur la boîte et dans la documentation. Comme son nom l'indique il nécessite 128 Ko de RAM, ce qui est impossible sur TO7 car il n'y a pas de mécanisme de commutation de pages.

En ce qui concerne l'incompatibilité de sddrive.sel avec la MEGAROM T2 : Le programme sddrive.sel est chargé en $9000, la pile système est en $9CFF et la zone $A000-$BFFF contient la liste des fichiers .sd présents sur la carte SD.

Le programme ne semble pas être écrasé, car le logo SDDRIVE et la première page de la liste s'affichent bien, par contre le programme détecte l'appui sur un bouton d'action en l'absence de l'extension musique et jeu. Normalement l'absence d'extension devrait être détectée, et dans ce cas le bouton d'action n'est pas testé. Hors il est testé, puisque le premier programme de la liste est sélectionné automatiquement sans aucune action de l'utilisateur. C'est ce que j'ai du mal à comprendre. Quand l'extension musique et jeux est présente, elle est bien détectée et tout fonctionne bien.

[__sam__]

Code : Tout sélectionner

;------------------------------------------------------
; Test de presence interface musique et jeux
;------------------------------------------------------
INIT1
  TFR   A,DP           ; DP = $20(MO) ou $60(TO)
  CLR   MJEUX          ; par defaut pas d'interface
  ADDA  #$87           ; $A7 ou $E7 
  LDB   #$CF           ; $CF
  TFR   D,U            ; adresse $A7CF ou $E7CF
  LDA   ,U             ; A=valeur registre CRB
  LDB   #$15           ; B=valeur peu probable de CRB
  STB   ,U             ; modification registre CRB
  LDB   ,U             ; lecture registre CRB
  ANDB  #$3F           ; 6 bits de poids faible
  CMPB  #$15           ; comparaison valeur lue/ecrite    
  BNE   INIT2          ; pas de controleur  
  STA   ,U             ; restauration registre CRB
  INC   MJEUX          ; indicateur de presence interface

Il n'y a pas l'intégralité du code plus haut, mais il me semble qu'en l'absence de contrôleur, on saute direct sur INIT2 (label manquant, mais que je suppose être le suivant) en laissant MJEUX à 0, mais surtout sans restaurer le CRB. Est-ce que c'est un bug, et est-ce que cela a une incidence plus loin en cas de MegaROM T2 ?

[Daniel]

Je me suis posé la même question en relisant le code. Mais non, c'est normal : dans ce cas l'extension n'existe pas, il n'y a donc rien à restaurer

[__sam__]

Que lit-on en $E7CB en l'absence de contrôleur, mais en présence de MegaROM ?

Si ca se trouve, la présence de la MegaROM force une valeur particulière à cette adresse flottante. C'est une électronique un peu plus sophistiquée que celles des ROM de base, va savoir ce que ca mets sur le bus en cas de haute impédance fourni par de l'électronique de 40+ ans.

Autre truc qui m'intrigue: si je pige bien le code tu mets une valeur sur le CNA et la relis par la suite. Si tu la retrouve, c'est que le CNA et donc l'extension musique&jeux est présente. Ok mais je ne vois pas l'init du port B en sortie. C'est du code amont, ou juste il se trouve que le port B est en sortie par défaut avec les basic standard (sauf quand on boot sur la megarom) ?

[Daniel]

En lançant le BASIC 1.0 avec la MEMO7 ou avec la MEGAROM on obtient exactement les mêmes valeurs pour la zone $E7CB-$E7CF, avec ou sans l'extension musique et jeux :
- Sans l'extension : $3E, $5E, $5E, $5E, $5E
- Avec l'extension : $3E, $FF, $CC, $04, $04

Pour tester la présence de l'extension, sddrive.sel teste le registre de contrôle du port B (CRB) à l'adresse $E7CF.
Ce registre a les 6 bits de poids faible en lecture-écriture, les deux bits de poids fort sont en lecture seule. Le test valeur lue = valeur écrite porte uniquement sur les 6 bits de poids faible. Mais le problème n'est pas là, puisque la MEGAROM ne change rien à ces registres.

Le problème est subtil et peut-être pas du tout où nous l'attendons. Ce n'est pas la pile système, car son pointeur est initialisé par sddrive.sel. Les interruptions sont masquées et ne peuvent donc pas perturber le programme. Il y a autre chose, mais où ?

Je mets ici le programme sddrive.sel complet, pour ceux qui veulent chercher.

sddrive_sel.zip

(32.34 Kio) Téléchargé 27 fois

[Fool-DupleX]

Effectivement, ce bug est déroutant. En tout cas, le logiciel de la Mégarom ne touche pas à l'extension ni à la zone de ram utilisée par le SDDrive.

va savoir ce que ca mets sur le bus en cas de haute impédance fourni par de l'électronique de 40+ ans.

Moi je sais : tant que le signal de validation de la MEMO7 est en haut, de la haute impédance compatible TTL. En plus l'électronique est beaucoup plus rapide, la transition se fait en 5 ns. Ceci dit, il n'est pas impossible que les signaux soient légèrement ralentis par le changement d'impédance, voire que cela provoque des rebonds, mais je n'ai jamais observé le moindre problème sur aucun modèle TO. Nous avons mis un soin extrême avec Prehisto. Il doit y avoir des centaines d'heures de test qui ont été faites avant la première release.

Et si on met une bêtise entre le STB ,U et le LDB,U ? genre un TFR A,A histoire de faire un peu plus de cycles que le NOP ... ?

[Daniel]

Je n'y croyais pas, mais j'ai quand même essayé de mettre TFR A,A entre STB,U et LDB,U.

Miracle
Ca marche. Il n'y a plus d'incompatibilité SDDRIVE-MEGAROM. De toute ma vie de thomsoniste je n'ai jamais rencontré une telle subtilité.
Nouvelle version de sddrive.sel :

sddrive.sel_20230707.zip

(3 Kio) Téléchargé 27 fois

Nouveau mystère
TFR A,A s'exécute en 6 cycles.
J'ai essayé de le remplacer par NOP NOP NOP. Ca ne résout pas le bug.
J'ai alors essayé NOP NOP NOP NOP (8 cycles). Ca ne résout pas le bug.
Comment peut-on l'expliquer ?

Avant de continuer la discussion, je remercie FoolDupleX d'avoir trouvé la solution et bruce7491 d'avoir signalé le problème. Maintenant il peut utiliser SDDRIVE avec la MEGAROM sur TO7/70

[Fool-DupleX]

Héhé.

[Daniel]

Et pourquoi ça ne marche pas avec les NOP ? Ce n'est pas seulement une question de temporisation ?

[__sam__]

La solution est peut-être dans l'état du bus entre le NOP (FETCH + DONTCARE) et le TFR (FETCH + POSTBYTE + DONTCARE + DONTCARE + DONTCARE + DONTCARE) ? Le TFR introduit un max de temps en haute impédance (don't care) sur le bus d'adresse. Il faut peut-être ca pour ne pas avoir de phénomène de rebond ou que sais-je. Un EXG ou un MUL seraient de bon candidats à tester aussi (MUL fait gagner un octet mais zigouille les registres).

Capture.PNG (37.72 Kio) Consulté 1233 fois

Capture.PNG (33.64 Kio) Consulté 1233 fois

(source: page 23 et plus du manuel 6809).

[Fool-DupleX]

Pour être tout à fait honnête, je n'ai pas l'explication exacte. Mais j'ai fait la même hypothèse peu ou prou que toi, Sam. D'où mon choix de TFR.

Ce qui est certain, c'est que le LDB ,U ne lit pas $5E. Et j'avais déjà remarqué quand j'étais gamin que la lecture du bus "quand il n'y a rien" (i.e. quand il est en haute impédance), dépend des instructions utilisées pour le lire, sans pouvoir toutefois l'expliquer.

Il me semble aussi que nous avons eu ce genre de discussion ici même par le passé, en lien avec la lecture de la RAM ou quelque chose dans le genre.

Il faudrait observer les signaux à l'analyseur logique, voire à l'oscilloscope pour en avoir le coeur net. Je suppose que la présence de la Mégarom sur le bus modifie l'impédance de ce dernier, ce qui a généralement deux effets concrets, le ralentissement des transitions et les rebonds. Tout se passe bien dans une certaine limite quand le bus est asservi, mais quand il est libéré, ces effets parasites sont rois.

[__sam__]

On va dire que c'est "tombé en marche"

[Fool-DupleX]

On va dire que c'est "tombé en marche"

Non, on ne va pas dire ça. J'ai l'habitude de travailler sur ce genre de phénomènes et en vérité, c'est modélisable. D'ailleurs on le fait systématiquement sur les technologies modernes et on compense en modifiant les protocoles. Sinon on ne pourrait pas atteindre les vitesses de ouf du type 300 GB/s.

Bref, ce que je voulais dire en fait, c'est que j'aimerais bien en avoir le coeur net une fois pour toutes. Je n'ai malheureusement pas le temps, comme d'habitude, d'y jeter un oeil, mais ca m'intéresse vivement.

Par contre, je ne vais pas modifier les paramètres de la CPLD de la Mégarom, ça n'en vaut pas le coup et ça risque de faire empirer le phénomène.

Après, je suis heureux que nous ayons trouvé une parade. Ce n'est pas un hasard, il y a nécessairement un fond de vérité dans cette discussion, sinon on serait encore en train d'essayer des trucs avec l'énergie du désespoir.

[Daniel]

L'objectif principal, tout le monde sera d'accord, est de faire fonctionner nos bricolages. Que ce soit SDDRIVE ou la MEGAROM, il faut avant tout que les utilisateurs puissent s'en servir. Cette incompatibilité devait être supprimée. Elle l'est, donc tout va bien. Grâce à l'intuition ou à la chance je trouve que ce comportement inattendu a été très vite corrigé compte tenu de sa subtilité (moins de trois jours après le signalement).

Après il reste la satisfaction intellectuelle, qui n'est pas encore complète. C'est frustrant de ne pas tout comprendre. Même s'il n'y a pas urgence, il serait bien d'avoir un jour une explication scientifique.

[__sam__]

Oui, tout à fait, car si ca se trouve on va peut-être découvrir qu'en ajoutant une extension en plus sur le bus du TO7 (*), le contournement actuel ne marche plus. C'est tout le problème du "tombé en marche": le phénomène a-t-il vraiment disparu ou s'est-il caché ailleurs ? Le temps nous le dira.
____
(*) quelqu'un a essayé les modules de captures vidéo qui se faisaient vers la fin des années 90 sur Thomson ? Ca ne court pas les rues...