forum.system-cfg.com

J'avais avant sa sortie fait des tests complet >> ICI << sur l'extension SDdrive V2.00 avec 4 autres personnes. Depuis elle a évolué et je pense que tout le monde en est content. Bien sûr cela n'exclus pas la panne comme tout matériel électronique mais cela n'exclus pas non plus la mauvaise utilisation.

jasz a écrit : ↑16 juin 2018 19:06

Code : Tout sélectionner

Machine  | SDDRIVE | Lecture | Ecriture | Reset | Commentaires          
---------|---------|---------|----------|-------|------------------------------------------------------
T9000    | Aucune  |         |         `|       | Pas d'extension 16ko
TO7/70   | V1      | Ok      |          | Non   | Impossible d'essayer l'ecriture
         |         |         |          |       | Le reset plante systématiquement
         | V2      | Ok      |          | Ok    | Ecriture impossible car Disk DOS impossible à charger
MO5 50001| V1      | Ok      | Ok       | Ok    |
         | V2      | Non     |          |       | Test à refaire sur une autre machine 50.001
MO5 Meca | V1      | Non     |          |       | 
         | V2      | Ok      | Ok       | Ok    |
MO6NR    | V1      | Ok      | Ok       | Ok    | Pas de chargement direct en BASIC128
         |         |         |          |       | Taper CLEAR,&H4FFF:EXEC&HA025
         | V2      | Ok      | Ok       | Ok    | Même remarque que précédemment
TO8      | V1      | Ok      | Ok       | Ok    | Pas de chargement direct en BASIC512
         |         |         |          |       | Taper CLEAR,&H8FFF:EXEC&HE025
         | V2      | Ok      | Ok       | Ok    | Même remarque que précédemment
TO8D     | V1      | Ok      | Ok       | Ok    | Pas de chargement direct en BASIC512 ou 1.0
         |         |         |          |       | Taper POKE&HE7E7,&HD4:EXEC&HE025
         |         |         |          |       | Après Disk chargé taper EXEC&HE007    
         |         |         |          |       | Le reset renvoie 3 erreurs 2 et bloque le retour au BASIC
         | V2      | Ok      | Ok       | Ok    | Même remarque que précédemment sauf
         |         |         |          |       | Le reset bloque le retour au BASIC directement
---------|---------|---------|----------|-------|------------------------------------------------------        

Je complèterai ce post avec d'autres tests mais déjà nous avons un bon comparatif entre les deux versions V1 et V2 de SDDRIVE

[edit]

Code : Tout sélectionner

Machine  | SDDRIVE | Lecture | Ecriture | Reset | Commentaires          
---------|---------|---------|----------|-------|------------------------------------------------------
MO5 50001| V1      | Ok      | Ok       | Ok    | Pas de chargement direct en BASIC1.0 sur les deux UC test et contrôle 
         |         |         |          |       | Taper CLEAR,&H4FFF:EXEC&HA025
         |         |         |          |       | Après Disk chargé taper EXEC&HA007 
         | V2      | Ok      | Ok       | Ok    |
TO7/70   | V1      | Non     |          |       | ?IO Error in 0
         |         |         |          |       | Le reset ne plante plus
         | V2      | Ok      | Ok       |       | Erreur ?NE in 0 après chargement du DOS
         |         |         |          |       | DOS bien présent
         |         |         |          |       | Le reset ne retourne pas au DOS
---------|---------|---------|----------|-------|------------------------------------------------------        

A noter qu'au fil des versions le comportement du contrôleur SDDRIVE a très légèrement évolué : pour supporter le DOS LOGO, pour éviter l'écrasement de paramètres quand la pile système se remplit, pour démarrer automatiquement en BASIC 128 ou 512, pour ne plus se bloquer en cas de carte SD incompatible ou d'absence de carte SD. Les premières versions sont toutefois pleinement opérationnelles dans la très grande majorité des cas.

Au cours de tests avec le TO7/70 je viens de constater un comportement anormal quand on utilise la version 2019.04.10 du contrôleur SDDRIVE avec le BASIC 128. Au premier lancement le programme de sélection sddrive.sel affiche le titre SDDRIVE et se bloque.

Bon, ce n'est pas grave, il suffit de réinitialiser le TO7/70 (par le bouton INIT PROG) et de relancer sddrive.sel par EXEC &HE007
Je n'ai pas encore trouvé la raison de cette anomalie, car le problème ne se produit pas avec l'émulateur dcmoto et il n'est pas facile de débuguer un programme avec la vraie machine. En attendant une prochaine correction il faudra utiliser la procédure ci-dessus (Initialisation + EXEC).

Le problème est identifié et corrigé :

Avec le TO7/70 en BASIC 128 la banque RAM sélectionnée par défaut est la dernière de l'extension mémoire. Si l'extension mémoire est absente, l'ancienne version du programme sddrive.sel ne fonctionne pas. Je crois qu'au cours des premiers tests Carl avait déjà signalé le problème.
Dans dcmoto ça marchait car l'extension mémoire est sélectionnée par défaut, mais si on l'enlève dans les options alors l'émulateur reproduit exactement l'erreur constatée avec la vraie machine.

J'ai ajouté dans le programme sddrive.sel la routine de sélection de la première banque de RAM si le BASIC 128 est détecté.
Le problème est résolu.
La version corrigée de sddrive.sel est dans l'archive sddrive_20190410.zip à la page officielle de SDDRIVE :
http://dcmoto.free.fr/bricolage/sddrive/index.html

Cette version fonctionne avec les EPROMs 20190212, 20190410 et suivantes.
Elle comporte aussi une autre amélioration : les flèches droite et gauche permettent de passer à l'écran suivant et à l'écran précédent, pour éviter de parcourir la liste ligne à ligne avec les flèches bas et haut.

ATTENTION : BUG !
Je viens de découvrir un bug du contrôleur SDDRIVE qui affecte les versions 2019.03.03 et 2019.04.10 de l'EPROM, diffusées entre le 08/03/2019 et le 24/06/2019. Les huit derniers contrôleurs vendus sont impactés.

L'erreur concerne la fonction d'écriture d'un secteur : l'adresse du buffer est erronée et l'écriture peut corrompre le système de fichiers.
Par contre toutes les opérations de lecture fonctionnent parfaitement bien, c'est pourquoi ce bug n'a pas été découvert immédiatement.
Si on se contente de charger des programmes, tout est bon. Le problème se manifeste, par exemple, si on sauve un fichier.

Conduite à tenir si vous avez l'une des deux mauvaises versions de l'EPROM :
- Si vous êtes équipés pour reprogrammer l'EPROM, utilisez la dernière version disponible ici --> http://dcmoto.free.fr/bricolage/sddrive/
- Si vous ne pouvez pas programmer l'EPROM vous-même, manifestez-vous dans ce fil de discussion, je vous enverrai l'EPROM de la dernière version pour remplacer la mauvaise.

Désolé pour ce problème. Les informaticiens comprendrons que ce genre d'erreur échappe parfois aux contrôles.
Pour la petite histoire, le registre DP n'avait pas la bonne valeur lors d'un adressage direct : LDY <DK_BUF

@Daniel je pense être dans les 8 derniers a avoir acheté un sddrive et malheureusement je n'ai pas l'équipement et les connaissances pour reprogrammer l'EPROM

@Brochiman : Aucun problème, j'envoie la nouvelle EPROM demain.

Pour retirer l'ancienne EPROM de son support, l'outil le plus pratique est une lame de canif.
Pour insérer la nouvelle, il faut procéder avec beaucoup de précautions :
- Bien respecter le sens, l'encoche de l'EPROM doit être du côté de l'encoche du support et de la sérigraphie.
- Ne pas appuyer tant que toutes les broches ne sont pas parfaitement positionnées. Elles peuvent se tordre très facilement, attention !

@Daniel je pourrais te renvoyer l'ancienne EPROM si tu le souhaites. Il faudra une nouvelle version de sddrive.sel sur la carte microSD?

Le timbre coûte plus cher que l'EPROM, il ne faut pas la renvoyer.
Les deux dernières versions du programme sddrive.sel sont compatibles avec l'EPROM 2019.06.26 :
- sddrive.sel de début 2019 (utilise uniquement les flèches haut et bas pour changer de ligne)
- sddrive.sel dernière version (utilise en plus les flèches gauche et droite pour changer d'écran).
Il n'est donc pas nécessaire de le changer. Toutefois, si les flèches gauche et droite ne sont pas programmées, autant prendre la dernière version.
Les versions antérieures à décembre 2018 ne sont pas compatibles.

Le bug de SDDRIVE introduit en février 2019 était également présent dans la version officielle 2019.02.20 de l'émulateur dcmoto.
Après correction la nouvelle version 2019.06.26 de dcmoto vient d'être mise en ligne à http://dcmoto.free.fr/index.html

Daniel a écrit : ↑12 janv. 2019 17:18 Eh bien non, ce n'est pas soft, c'est hard, je viens de le constater.

J'ai un autre MO6 de série W7G 001040. Il a exactement la même carte mère et la même ROM (j'ai vérifié). Avec la dernière version de SDDRIVE le programme de sélection démarre automatiquement, dès qu'on lance l'un ou l'autre BASIC par l'option 1 ou 2.

J'ai soupçonné l'alimentation, et donc je les ai échangées pour vérifier. Ce n'est pas ça, le premier MO6 se bloque avec l'une ou l'autre alimentation, le deuxième MO6 démarre toujours bien avec l'une ou l'autre alimentation. C'est donc un composant de la carte mère.

J'ai d'abord soupçonné les condensateurs électrolytiques (perte de capacité). En mettant en parallèle des condensateurs neufs il n'y a pas de changement, ce n'est donc pas ça. Je ne sais plus trop comment trouver l'élément défectueux, car c'est très subtil. En dehors de ce blocage au démarrage le système fonctionne parfaitement bien, y compris lorsqu'il lit ou écrit sur la carte SD par l'intermédiaire du contrôleur SDDRIVE.

Bon, ce n'est pas dramatique, car même si quelqu'un rencontre le même problème il y a la solution donnée dans mon post précédent. C'est plus par curiosité intellectuelle que je voudrais trouver la particularité de ce MO6, quitte à changer un par un tous les composants.

Pas de bol, le MO6 que je viens de récupérer présente un autre dysfonctionnement qui empêche totalement l'utilisation du SDDrive :'(

En appuyant sur 1, le voyant rouge du SDDrive s'allume, le fond de l'écran devient gris (le texte reste, la bordure ne change pas de couleur) et rien ne se passe.
Faire reset et réappuyer sur 1 ne change rien.

En appuyant sur 2, le voyant rouge du SDDrive s'allume, on voit les 2 octets de couleurs en haut à droite habituels lors du boot et... rien. Figé.
Idem, faire reset et réappuyer sur 2 ne change rien.

Edit : je viens de remarquer qu'avec 1, le voyant rouge ne s'allume plus lors de la tentative après le reset. Alors qu'avec 2 il continue de s'allumer à la tentative après reset.

J'ai mis des photos, ainsi que les références du MO6 en question ici : https://photos.app.goo.gl/G8VxecWuyGnscm85A

Ce MO6 a manifestement été conservé dans des conditions douteuses (il est sale et abimé) mais le connecteur d'extension avait encore son cache et il est propre (comme neuf)
Tout fonctionne par ailleurs (clavier, port cartouche, crayon optique et, même, lecteur de K7)

C'est étrange que seuls les MO6 présentent ces dysfonctionnements... je me demande s'ils n'auraient pas été fabriqués avec des composants de moins bonne qualité... (condensateur?)

Faute de comprendre la raison, j'ajoute quelques autres observations pouvant avoir un rapport :

- Je connais 3 versions différentes de la ROM MO6. Je les appelle U, V et W en référence au numéro de série inscrit sur l'étiquette sous le MO6, mais il semble que la règle ne soit pas absolue car j'ai trouvée au moins une exception. La carte mère ne correspondait peut-être pas au boîtier, alors on ne peut rien dire de plus.

- J'ai essayé SDDRIVE avec un MO6 équipé d'une ROM d'Olivetti PC128, avec succès. J'ai aussi fourni SDDRIVE à un italien pour son PC128 et il n'a pas eu de problème.

- Le contrôleur de QDD CD90-028 a aussi un comportement bizarre avec les MO6, tout comme SDDRIVE. Il ne serait pas étonnant qu'il y ait un lien entre les deux phénomènes. Voir ici pour le QDD : http://dcmoto.free.fr/forum/messages/652331_0.html
D'après les photos le MO6 d'OlivierH semble avoir un numéro de série commençant par V, c'est précisément celui avec lequel le QDD fait planter l'ordinateur au démarrage.

J'ai une hypothèse (non confirmée) pour les raisons des modifications de la ROM : la compatibilité avec le contrôleur nanoréseau. Comme par hasard la série U, qui fonctionne bien avec le QDD, ne fonctionne pas en nanoréseau. La série W est la plupart du temps marquée "MO6NR" au lieu de "MO6", elle fonctionne bien en nanoréseau mais pas avec le QDD. C'est assez troublant.

Il y a aussi de grosses différences de comportement entre le BASIC128 et le BASIC 1.0, mais c'est purement soft.

Il est aussi possible que les dernières versions de l'EPROM SDDRIVE ne réagissent pas exactement comme les premières, car il y a eu pas mal d'améliorations, en particulier dans le traitement des erreurs d'accès à la carte SD. Mais je doute que ça change le fond du problème.

Pour l'instant le mystère reste entier, car mes essais montrent que deux MO6 apparemment identiques et avec la même ROM ont des comportements différents avec SDDRIVE. Alors problème soft, ou problème hard, ou les deux à la fois, difficile de trancher. Toute nouvelle information sera la bienvenue.

Ca pourrait être intéressant de comparer l’électronique d'un MO6 qui marche avec un qui ne marche pas.
Vu qu'à priori ça ne vient pas de la ROM ni de l'alimentation, ça ne peut venir que d'une histoire de composant différent...

Edit : je vais voir si je ne peux pas récupérer un deuxième MO6, d'une série qui ne poserait pas de problème, pour tenter de faire des comparaison ^^

Ce n'est pas facile, j'ai déjà essayé mais je n'ai rien trouvé. La difficulté pour les tests sur la vraie machine est l'absence de debugger, on ne voit pas où le programme se plante et on ne peut pas l'exécuter pas à pas. La seule possibilité est d'utiliser un analyseur logique, mais ce n'est pas facile à mettre en œuvre et à interpréter.

C'est pourquoi il faut recueillir le maximum d'informations, en espérant que nous découvrirons la clé du mystère par recoupements. Tous les partages d'expériences sont utiles.

[EDIT 02/07/2019]
Une expérience intéressante serait d'essayer, avec ce MO6 récalcitrant, un contrôleur officiel Thomson (CQ90-028, CD90-015, CD90-640 ou CD90-351), pour voir s'il fonctionne ou pas. Chez moi, le MO6 série V plante au démarrage avec le contrôleur CQ90-028, ce qui semble mettre SDDRIVE hors de cause. Mais ça n'explique toujours pas la raison du plantage.

Bonjour,

J'ai quelques questions/remarques à propos de l'utilisation de SDDRIVE sur TO8 (sans lecteur de disquettes) Je précise que j'ai pu tester plusieurs programmes commerciaux avec succès. J'ai eu plus de mal avec les démos : pour l'instant je n'ai pu lancer que "Space Project".

-- On peut obtenir l'écran du choix de disquettes par EXEC &HE025 ; il apparaît aussi parfois si l'on fait le choix du basic 1.0 ou "exploitation de fichiers" sans que j'aie compris si c'était systématique.

-- Y a-t-il un moyen simple de restaurer la palette d'origine (faute de quoi l'écran de choix peut être illisible) ?

-- Le bouton RESET ne purge pas la mémoire : il en résulte parfois des bugs d'affichage sur l'écran de choix (après utilisation de jeux).

-- qu'appelle-t-on "disquette bootable" ? Cela fait-il référence à certaines démos ?

-- Comment créer une disquette vierge sur la carte SD ? Comment peut-on copier une disquette réelle en fichier .sd directement sur le TO8 (sans passer par un PC auxiliaire) ? Par exemple, peut-on charger des programmes basic d'une vraie disquette en mémoire puis les sauver sur la carte SD ?

Merci !