[Thomson] SDDRIVE

[Daniel]

Bonjour, question certainement déjà posée, mais un peu la flemme de parcourir le 80 pages du topic.
Y a t il un moyen hard de connecter un sddrive à un TO9 ? A l intérieur ? Forcément, c est la seule machine que j ai, mon premier ordi d ailleurs, et j aimerai bien me passer des disquettes.
Si ce n est pas possible, j ai quoi d autres comme solution ? La cartouche multirom ?
Merci bcp.

Le TO9 est incompatible avec tous les contrôleurs de disquette externes, y compris les QDD, les contrôleurs nanoréseau, les contrôleurs de cartes SD.
Il est compatible avec la Megarom, qui le transforme en console de jeu, mais ce n'est pas le même usage qu'un simulateur de disquettes.

En dehors de l'aspect nostalgie, le TO9 n'a pas grand intérêt. Pourtant il y a encore des amateurs qui le recherchent et il garde une valeur marchande élevée malgré ses limites. Il doit être assez facile de l'échanger contre un TO8, aux possibilités incomparablement supérieures.

[Daniel]

Sur les conseils de __sam__ je viens d'ajouter la possibilité de sélectionner le fichier .sd avec l'une ou l'autre des manettes dans le programme sddrive.sel.
Cette fonction s'ajoute à la sélection par les quatre flèches et ENTREE, toujours possible.
La nouvelle version est disponible à la page officielle de SDDRIVE : http://dcmoto.free.fr/bricolage/sddrive/index.html
Elle fonctionne avec toutes les versions récentes du firmware SDDRIVE à partir de 2019.
Si vous avez une version plus ancienne je vous conseille de me contacter pour mettre à jour l'EPROM.

sddrive.sel_20221109.png (9.5 Kio) Consulté 1795 fois

[repetto74]

Bonjour,

J'ai monté un SDDRIVE en utilisant la plaquette fournie par Daniel+fichier JED à programmer et en me procurant les composants nécessaires.
Toutefois je n'ai pas réussi pour le moment à le faire fonctionner sur le MO5. En allumant j'ai les problèmes suivant:

- le MO5 démarre normalement sur le basic (il semble ne pas voir du tout la présence du SDDRIVE connecté au bus d'extension via le minibus)
- la led verte alim ne s'allume pas

dépannage:

- j'ai vérifié les 5v sur le GAL, le 74ls125 et la eprom et j'ai les bonnes tensions.

Il est possible que la led verte soit HS ou monté à l'envers mais cela ne devrait pas empêcher le démarrage du firmware du SDDRIVE.
Les composants utilisés proviennent tous de Chine donc j'ai toujours un doute sur leur qualité. J'ai eu quelques soucis pour programmer le JED sur la GAL et j'ai du décocher l'option du check ID donc il se peut qu'il s'agisse d'une GAL renommée et pas la bonne. Pour la eprom même soucis avec le check ID du programmeur mais après tout semblait ok et programmation+vérification ok.
La carte SD est formatée en FAT32 avec le fichier .SEL fourni avec le binaire à programmer sur l'eprom.
Le minibus est ok car déjà utilisé avec un SD Stream sans aucun soucis.

Si des conseils sur d'autres choses à vérifier je suis preneur

IMG_4280.JPG (155.23 Kio) Consulté 1752 fois

[__sam__]

Il faut regarder les lettres en &HA000-&HA001 pour savoir si le contrôleur est monté.

Code : Tout sélectionner

? CHR$(PEEK(&HA000));CHR$(PEEK(&HA001))

Doit afficher ST avec SDDrive sur MO5.

[Daniel]

La LED verte peut avoir été détruite en la soudant. En la collant au circuit imprimé les pattes sont trop courtes et transmettent la chaleur du fer à souder. J'ai déjà eu le problème. Il faut souder très vite avec un fer pas trop chaud (moins de 350 °C). Il suffit de vérifier la tension aux bornes : si elle est de 5V, ou de 0V, il est presque certain que la diode est mauvaise (coupée ou en court-circuit).

Une autre piste peut être la sensibilité de la LED. Les miennes fonctionnent avec une intensité infime, j'ai mis en série avec le 5V une résistance de 20K pour qu'elles ne soient pas trop brillantes. Avec une LED moins sensible, il faut une résistance plus faible, par exemple 1K, sinon elle peut ne pas éclairer. Pour la LED rouge, beaucoup moins sensible, j'ai mis une résistance de 1K.

Pour le reste, je mettrais en doute les composants chinois. Ce sont toujours des composants de récupération extraits de vieilles cartes, et très souvent maquillés avec de fausses inscriptions. Il est anormal que l'identification de l'EEPROM ne soit pas reconnue. C'est la preuve que ce n'est pas une vraie W27C512. Si la programmation et la vérification ne produisent pas d'erreur, elle doit pourtant être utilisable. Par contre s'il n'y a pas un vrai GAL16V8 il est fort possible que le décodage d'adresse ne fonctionne pas bien, et ne sélectionne pas l'EEPROM quand il le faut. C'est parce que l'EPROM n'est pas sélectionnée que le MO5 ne détecte pas le contrôleur. Pour vérifier il faut taper la commande PRINTPEEK(&HA6FF), on doit obtenir 220. (Ou la commande donnée par __sam__, il a été plus rapide que moi pour poster )

Pour affiner le diagnostic il faudrait essayer avec des composants testés sur un autre SDDRIVE. Eventuellement m'envoyer le GAL et l'EEPROM pour que je les vérifie. Il n'est pas rare d'avoir ce genre de mésaventure. Ca m'arrive de temps en temps, c'est pourquoi je contrôle toujours un à un les composants reçus et je teste soigneusement le montage terminé.

Il arrive aussi que les pattes soient oxydées et provoquent de mauvais contacts, un petit nettoyage n'est pas du luxe.

[repetto74]

Bonsoir Daniel,

Merci pour tes précieux conseils
Je vais faire le test de la ligne basic et voir ce que je reçoit comme réponse du MO5. Pour la led je vais la remplacer avec une plus petite.
Pour info le GAL utilisé fait partie d'un lot utilisé également pour un projet multicartouche Colecovision et qui lui fonctionne normalement.
Donc soit comme tu dit c'est un GAL maquillé qui pose problème spécifiquement pour les fonctionnalités SDDRIVE, soit pas de bol celui monté est défaillant soit il a les pattes oxydés.
Bon je vais m'y mettre et je vais voir

[repetto74]

Salut Daniel,

Test rapide avec les commandes basic et les retours ne semblent pas corrects. Ca confirme donc que je dois me pencher sur le fonctionnement du GAL je pense.
Pour info le composant est marqué ATMEL16V8B donc je ne sais pas si ça fait une différence par rapport au GAL16V8. Je pense qu'ils sont équivalents.

IMG_4283.JPG (43.24 Kio) Consulté 1648 fois

IMG_4282.JPG (94.4 Kio) Consulté 1648 fois

[Daniel]

Le GAL est un bon suspect.
L'EEPROM peut aussi être défectueuse, mais c'est moins probable si le programmateur n'a pas trouvé d'erreur à la vérification.
Les mauvais contacts sont aussi très fréquents, pas seulement avec les pattes des composants mais aussi avec le connecteur d'extension du MO5. Il serait bon de le nettoyer, et d'enfoncer et retirer plusieurs fois le connecteur du minibus. C'est un problème souvent rencontré.

[repetto74]

Merci Daniel,

Je vais dessouder la GAL et installer un socle.
Changement de la led. Nettoyage des pattes du GAL et des connections du bus MO5.
Piocher une nouvelle GAL dans le lot et la programmer.
Bref au boulot

[Daniel]

[Hors-sujet]
Il y a quelques jours nous nous interrogions sur le genre de checksum. Masculin ou féminin ? Je disais "une checksum" mais d'après quelques sources s'est "un checksum". Ca semble bizarre, car "somme" est féminin, mais checksum est (paraît-il) masculin. C'est un "total de contrôle".

On peut s'interroger de la même façon sur le genre de GAL (Generic Array Logic). Je disais une GAL, car "logique" est féminin, mais il semble qu'il faut dire un GAL (Un circuit logique).

Et pour COVID l'Académie Française préconise le féminin (Disease = Maladie), alors que tout le monde dit le COVID (Disease est neutre en anglais).

Bref on n'y comprend rien, mais c'est comme ça. Alors j'écris "un GAL".
COVID au féminin et checksum au masculin me plaisent beaucoup moins car ça me semble très illogique. J'ai du mal à m'y faire.

[repetto74]

Salut Daniel,

J'ai eu un peu de temps pour tenter le dépannage du SDDRIVE mais sans succès
J'ai nettoyé les contacts du port expansion MO5 et du minibus. Ils sont fonctionnels avec le SDTREAM donc pas en cause.

J'ai récupéré une GAL16V8A fonctionnelle d'un autre projet que je n'utilise pas. Programmation et vérif OK.
J'ai effacé et programmé à nouveau la W27C512. Tout était ok sauf check ID qui doit être décoché donc cette eprom n'est pas une Winbond 27C512.

Même résultat et démarrage sur le Basic du MO5.

Deux choses:
- l'eeprom est maquillée et son adressage mémoire n'est pas celui attendu
- un problème sur le fichier JED du GAL?

Je vois rien d'autre à part le 74LS125. J'ai vérifié la continuité des pattes par rapport au schéma et tout semble ok.
J'ai remplacé la LED et maintenant elle s'allume faiblement (comme tu as dit c'est probablement du à la résistance de valeur trop grande).

J'ai plus trop d'idée la
On dirait que le contenu de la eeprom n’est pas lu en mémoire sur le MO5. J’exclue à ce point le GAL puisqu’il fonctionne sur l’autre projet et la programmation c’est faite sans soucis.

[Daniel]

J'ai vérifié le fichier JED, c'est le bon. Pour être sûr je le mets à nouveau ci-dessous :

sddrive_202206_jed.zip

(1.16 Kio) Téléchargé 50 fois

Le 74LS125 n'est pas utilisé pour le décodage d'adresse ni pour la sélection de l'EEPROM. S'il est défectueux il peut faire planter le MO5, mais sinon il ne peut pas empêcher d'accéder à l'EEPROM.

La carte SD n'est pas en cause, car le PRINT PEEK(&HA6FF) est complètement indépendant et donnerait la bonne valeur si la ROM était accessible, même sans carte SD et même sans 74LS125.

Reste l'EEPROM. Il faudrait essayer de la changer.

En dernier recours tu peux m'envoyer le SDDRIVE. En échangeant les composants avec un SDDRIVE opérationnel je trouverai la cause de la panne.

[EDIT]
Je pense à un dernier truc tout bête : le module de la carte SD a une partie métallique, il ne faut surtout pas qu'elle entre en contact avec les soudures du circuit imprimé. Quand le monte un SDDRIVE je coupe très court les pattes des composants, je fais des soudures ultra-plates et je mets une petite cale isolante pour éviter tout risque de contact.

[repetto74]

Salut Daniel,

Concernant le module SD je te confirme qu'il n'y a aucun risque de court circuit j'y avait déjà prêté attention
Je vais faire un test en programmant à nouveau le GAL avec le JED que tu as envoyé histoire de lever le doute.

Je pense aussi que la eprom est suspecte. Je me vais essayer de concatener le binaire pour remplir complètement la eprom, peut être un problème d'adressage et là où l'eprom est lue il n'y a rien Si cette eprom n'est pas une 27C512 ça pourrait expliquer aussi le problème.

Si rien ne va alors je penserais sérieusement à te l'envoyer

[Daniel]

Ah oui, je n'y avait pas pensé car c'est tellement naturel pour moi : il faut remplir les 64 Ko de l'EEPROM.
Les bits d'adresse de poids fort sont tous connectés au +5V, la plage de 2 Ko utilisée est donc la dernière.
On peut laisser à FF (hexa) les 62 Ko en partie basse inutilisée. Ou préparer un fichier de 64 Ko en reproduisant 32 fois le fichier de 2Ko :

sddrive_rom_64k.zip

(2.13 Kio) Téléchargé 48 fois

J'vais signalé ce point dans les premières versions de la documentation de SDDRIVE, mais je m'aperçois qu'il a disparu dans la version actuelle. Je vais immédiatement l'ajouter pour éviter l'erreur. Si tu as seulement programmé les premiers 2 Ko de la W27C512 il ne faut pas chercher plus loin, le problème est là. En remplissant les 64 Ko tout va bien fonctionner. Si ta fausse EEPROM a une capacité inférieure, par exemple 16 Ko, ça marchera aussi, mais une erreur sera peut-être signalée si tu cherches à la programmer avec un fichier de 64 Ko.

Le choix de la W27C512 est économique : c'est la moins chère. C'est aussi la plus commune et la plus facile à trouver. Mais sa taille est bien supérieure à celle d'un contrôleur de disquette Thomson et elle est nettement sous-exploitée.

[repetto74]

Salut Daniel,

Ah mais alors ça change tout en effet!! .
Je vais remplir la 27c512 avec le bon binaire et je suis confiant que ce la marchera enfin