[Thomson] SDDRIVE

Placez ici vos trucs et astuces, étalez sans retenue votre savoir-faire et votre science qui va nous permettre de redonner une apparence neuve et fonctionnelle à nos bouzes.

Modérateurs : Papy.G, fneck, Carl

jasz
Messages : 1313
Inscription : 05 oct. 2016 20:05
Localisation : Quelque part dans le 31

Re: [Thomson] SDDRIVE

Message par jasz »

Dans le cas de Daniel c'est uniquement sur Thomson. Mais je pense que si une personne reprenait l'idée, elle pourrait être compatible (l'idée) avec d'autres machines ;)
Daniel
Messages : 17319
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [Thomson] SDDRIVE

Message par Daniel »

SDDRIVE, comme son prédécesseur CS91-280, émule un contrôleur de disquette Thomson. Il est utilisé conjointement avec le BASIC-DOS Thomson et ne fonctionnera pas avec d'autres ordinateurs, à moins de refaire tout le soft de la machine cible. C'est hors de portée d'un amateur.

Par contre les spécialistes d'autres machines peuvent s'inspirer de la technique de SDDRIVE pour réaliser l'équivalent. C'est assez facile quand il existe déjà un contrôleur de disquette, il suffit de modifier légèrement le soft pour créer celui du contrôleur de carte SD. C'est beaucoup plus difficile quand on n'a pas de contrôleur de disquette (je pense au VG5000). Pas impossible, toutefois, puisque Darren Atkinson l'a fait pour Alice.
Daniel
L'obstacle augmente mon ardeur.
Lesarthois
Messages : 203
Inscription : 13 mai 2016 22:21

Re: [Thomson] SDDRIVE

Message par Lesarthois »

Voilà, ma question était très imprécise, mais Daniel a bien saisi le sens de ma question :wink:
__sam__
Messages : 7924
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE

Message par __sam__ »

jasz a écrit : 24 nov. 2017 16:57 Comment un simple 8bits qui ne comprend un système d'adressage que sur 16bits va réussir à lire dans une mémoire qui sera forcément sur 32bits? :shock:
C'est du streaming. Le thomson n'accède à la carte SD qu'au travers d'une fenêtre de 1 bit. Si on programme la carte SD pour qu'elle stream son contenu bit à bit à partir d'une position donnée, on arrive à la lire complètement. Mais ca n'est pas un accès random (le R de RAM). On ne peut pas sauter comme ca d'une position à une autre. Là c'est un accès séquentiel (le S de Sam.. heu non mais presque :P ).
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
jasz
Messages : 1313
Inscription : 05 oct. 2016 20:05
Localisation : Quelque part dans le 31

Re: [Thomson] SDDRIVE

Message par jasz »

Lesarthois a écrit : 24 nov. 2017 17:43 Voilà, ma question était très imprécise, mais Daniel a bien saisi le sens de ma question :wink:
J'ai répondu à ta question de manière tout aussi imprécise, jusqu'a ce que Daniel confirme ma réponse de manière plus précise. ;)
__sam__ a écrit : 24 nov. 2017 18:23 C'est du streaming. Le thomson n'accède à la carte SD qu'au travers d'une fenêtre de 1 bit. Si on programme la carte SD pour qu'elle stream son contenu bit à bit à partir d'une position donnée, on arrive à la lire complètement. Mais ca n'est pas un accès random (le R de RAM). On ne peut pas sauter comme ca d'une position à une autre. Là c'est un accès séquentiel (le S de Sam.. heu non mais presque :P ).
Ok mais je parlais de la RAM. See below ;)
jasz a écrit : 24 nov. 2017 16:57
Daniel a écrit : 24 nov. 2017 14:37Un MO5 avec 32 Go de RAM, en quelque sorte. Ca fait rêver, et je crois bien que ça pourrait être le sujet d'un prochain projet. Ce serait l'équivalent du montage pour SDANIM7, mais sans passer par le 6821, directement sur le bus. Et avec l'écriture en plus.
Enfin 1mo aurait déjà était très bien. C'est aussi un formidable projet. Mais...
Comment un simple 8bits qui ne comprend un système d'adressage que sur 16bits va réussir à lire dans une mémoire qui sera forcément sur 32bits? :shock:
__sam__
Messages : 7924
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE

Message par __sam__ »

Oui toi tu parles de RAM au sens mémoire à accès direct. Daniel parle de RAM au sens de mémoire, et plus spécifiquement celle de la carte SD qui n'est pas du tout à accès direct. Les deux n'ont pas trop de rapports.

Sinon pour répondre à ta question le dépassement des 64k est déjà présent dans les TO7/70 et autres TO8/9/9+. L'astuce passe par de la commutation de bank mémoire: aux adresses $A000-$DFFF on peut faire apparaître l'une quelconque des pages mémoire de 16ko de l'extension mémoire. C'est clairement un truc chiant à mettre en oeuvre (sur TO7 et TO9 du moins) et pas pratique à utiliser et peu de jeux ou programmes ne l'utilisent pleinement (sauf le basic qui est capable d'avoir des tableaux sur plusieurs banks). Mais ça permet d'avoir 512Ko sur un TO8. Autant de RAM que dans mon premier Amiga :)
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 : 17319
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [Thomson] SDDRIVE

Message par Daniel »

En attendant un SDDRIVE réel, voici une première ébauche du modèle virtuel.
Le module avec la carte SD se branche au connecteur noir à droite.
(en vrai les condensateurs sont beaucoup plus petits et les résistances ne sont pas roses)
Pièces jointes
sddrive_3dview.png
sddrive_3dview.png (176.44 Kio) Consulté 6634 fois
Daniel
L'obstacle augmente mon ardeur.
jasz
Messages : 1313
Inscription : 05 oct. 2016 20:05
Localisation : Quelque part dans le 31

Re: [Thomson] SDDRIVE

Message par jasz »

__sam__ a écrit : 24 nov. 2017 21:12 Oui toi tu parles de RAM au sens mémoire à accès direct. Daniel parle de RAM au sens de mémoire, et plus spécifiquement celle de la carte SD qui n'est pas du tout à accès direct. Les deux n'ont pas trop de rapports.
Ah! Ok! En effet, je ne l'avais compris ainsi. Arf :oops:
Daniel a écrit : 24 nov. 2017 22:21 En attendant un SDDRIVE réel, voici une première ébauche du modèle virtuel.
...
(en vrai les condensateurs sont beaucoup plus petits et les résistances ne sont pas roses)
Franchement! Chapeau bas 8)
Pour les résistances roses, on a qu'à dire que c'est pour colorer :wink:
Daniel
Messages : 17319
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [Thomson] SDDRIVE

Message par Daniel »

__sam__ a écrit : 24 nov. 2017 11:28 Perso j'aime bien SDSEL sur la D7 ca permet de pouvoir le remplacer en cas de bug.
Dans sa version actuelle, le contrôleur CS91-280 recherche sur la carte SD la disquette BOOT.SD, il la "monte" comme on dit dans Linux. Ensuite c'est le moniteur de l'ordinateur Thomson qui prend le relais. Si BOOT.SD n'a pas de secteur de boot, il cherche l'AUTO.BAT et le lance, ce qui charge et exécute SDSEL.BIN. C'est assez rapide. Par contre, pour les ordinateurs n'ayant que le BASIC 1.0, la disquette BOOT.SD doit contenir le DOS, qui se charge avant le lancement de SDSEL. C'est long (environ 6 secondes), et inutile pour lancer un jeu possédant son propre secteur de boot. C'est ce que je voulais éviter en mettant SDSEL dans l'EPROM.

J'ai une autre idée, qui va certainement nous mettre d'accord : le contrôleur SDDRIVE, au lieu de chercher le fichier BOOT.SD et de lancer tout le processus ci-dessus, peut chercher directement le fichier SDSEL.BIN, le charger et l'exécuter. Ce programme est tout petit et ne nécessite pas le DOS. Le chargement ne dépassera pas quelques dixièmes de secondes. Le DOS sera chargé plus tard, si l'utilisateur choisit une disquette le contenant. On se rapproche davantage du fonctionnement d'un ordinateur Thomson avec les "vraies" disquettes.

Finalement il sera inutile de compresser, il restera même 300 octets libres dans l'EPROM, il faudra y mettre un Easter egg.
Daniel
L'obstacle augmente mon ardeur.
Avatar de l’utilisateur
petitjd
Messages : 2007
Inscription : 23 oct. 2007 11:50

Re: [Thomson] SDDRIVE

Message par petitjd »

Daniel a écrit : Finalement il sera inutile de compresser, il restera même 300 octets libres dans l'EPROM, il faudra y mettre un Easter egg.
La photo de Daniel, prise par une DI 90-011, qui apparait en tapant simultanément sur les touches "M" "O" "5" :mrgreen:
PetitJD
Tortue Jeulin: www.tortue-jeulin.com
Nanoreseau: www.nanoreseau.net
Proteus III: www.proteus-international.fr
Avatar de l’utilisateur
Papy.G
Modérateur
Messages : 3047
Inscription : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: [Thomson] SDDRIVE

Message par Papy.G »

Je suis heureux pour les possesseurs de Thomson qu'arrive cette évolution, bien que le SDMOTO présentait déjà bien des avantages, et je ne suis pas étonné que tu y sois arrivé, mais chapeau quand-même.
Daniel a écrit : 24 nov. 2017 14:37Pour lire 8 bits en parallèle le plus simple est d'avoir un Arduino en interface.
Pour les intégristes du périphérique "comme à l'ancienne", l'ajout de registres à décalage compliquerait-il vraiment beaucoup le truc? :?
Sinon, il existait des microcontrôleurs capables de gérer le SPI (même avant que ce soit intégré dans leurs fonctions spécifiques), le 8051, par exemple, voire même en version à faible nombre de pattes (89C2051). :P
Evidement, on doit être entre 5 et 10 fois le coût du montage avec un Arduino. :mrgreen:
jasz a écrit : 24 nov. 2017 16:57Enfin 1mo aurait déjà était très bien. C'est aussi un formidable projet. Mais...
Comment un simple 8bits qui ne comprend un système d'adressage que sur 16bits va réussir à lire dans une mémoire qui sera forcément sur 32bits? :shock:
La taille maximum d'un bloc accessible octet par octet est de 65535octets (64kO) avec un adressage sur 16bits, si le processeur différencie la zone où il exécute le programme et celle où il stocke les données, on peut envisager des blocs jusqu'à 64kO, on adresse les banks par les bits de poids plus forts de l'adresse au-delà des 16bits, ou moins, adressés directement par le processeur. Dans une mémoire de masse, c'est souvent l'inverse: on adresse les blocs par les bits de poids forts de l'adresse, puis, lors de la lecture, on égrène le bloc de façon séquentielle, bit par bit ou octet par octet selon le contôleur.
jasz a écrit : 24 nov. 2017 17:30Dans le cas de Daniel c'est uniquement sur Thomson. Mais je pense que si une personne reprenait l'idée, elle pourrait être compatible (l'idée) avec d'autres machines ;)
Il y a l'Hectorduino, pour ne citer qu'un exemple sur ce forum. :wink:
__sam__ a écrit : 24 nov. 2017 21:12Oui toi tu parles de RAM au sens mémoire à accès direct. Daniel parle de RAM au sens de mémoire, et plus spécifiquement celle de la carte SD qui n'est pas du tout à accès direct. Les deux n'ont pas trop de rapports.
Daniel a écrit:
Daniel a écrit : 24 nov. 2017 14:37Et alors la vitesse de lecture de la carte SD devient identique à la vitesse de lecture de la RAM. Un MO5 avec 32 Go de RAM, en quelque sorte.
Il était donc question de comparer la vitesse d'accès aux données, pas nécessairement le mode d'adressage de cette mémoire de masse, mais l'ordinateur ne fera pas la différence, si les données sont lues dans un tampon en Ram à la vitesse maximum où il peut faire les transferts (Lda-Sta).
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.
Daniel
Messages : 17319
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [Thomson] SDDRIVE

Message par Daniel »

Des nouvelles du projet SDDRIVE : La mise au point de l'interface avec la carte SD continue.

Pour le MO5 on peut considérer que c'est terminé. Après l'ajout des filtres sur les lignes d'adresses le fonctionnement est fiable à 100%.

J'ai ensuite attaqué les essais sur TO8, pensant que ce serait une simple formalité. Eh bien non. Au premier essai, la carte SD ne s'initialise pas. Je cherche un peu avec l'analyseur logique : tous les signaux envoyés sont bons, mais la carte ne répond pas à la commande CMD0 (Go iddle state). En examinant la forme des créneaux à l'oscilloscope on ne voit rien d'anormal, sauf que la tension d'alimentation est anormalement élevée : 5,2V au lieu des 5,0V réglementaires. Un peu au hasard je mets une LED en série avec le +5V, la tension tombe à environ 4V et le miracle se produit : ça marche.

Je crois que ça va être vite réglé en ajustant la tension du TO8 à 5V. Mais non : avec une tension de 5,00V ça ne marche pas, ni avec la LED en série, ni sans la LED. J'ai tout essayé : augmenter la valeur des condensateurs de découplage des circuits logiques, mettre des résistances de pull up ou de pull down, diminuer la longueur des fils de liaison avec le TO8, rien n'y fait. Par contre, en remontant la tension du TO8 à 5,2V et en mettant la LED en série ça marche toujours. C'est dans ces cas là qu'on regrette de ne pas être électronicien. Là je suis un peu bloqué, en attendant de nouvelles idées...

Côté soft, par contre, il y a des progrès : l'écriture d'un octet prend maintenant 50 cycles au lieu de 64. Dans un premier temps j'avais remplacé le ROLB / STB <$BF par un ROL <$BF, pour gagner une instruction. Grosse erreur : le ROL fait deux accès successifs à la mémoire, séparés par un cycle. Résultat : il envoie deux tops d'horloge à la carte au lieu d'un, et donc ça ne marche pas. J'ai passé plus d'une demi-journée à trouver le bug. Finalement j'ai trouvé la bonne solution, qui n'utilise plus le registre B et gagne 2 cycles à chaque écriture d'un bit. Voici le code pour la lecture et l'écriture :

Code : Tout sélectionner

*------------------------------------------------------
* LECTURE D'UN OCTET (SDDRIVE) = 50 + 5 cycles
* Le registre B n'est pas preserve
* Valeur de l'octet dans le registre A en sortie
*------------------------------------------------------
RBYTE
  LDB   #$7F          initialiser B pour lecture (2)
  CMPB  <$BF          lecture bit 7              (4)
  ROLA                pousser dans A             (2)
  CMPB  <$BF          lecture bit 6              (4)
  ROLA                pousser dans A             (2)
  CMPB  <$BF          lecture bit 5              (4)
  ROLA                pousser dans A             (2)
  CMPB  <$BF          lecture bit 4              (4)
  ROLA                pousser dans A             (2)
  CMPB  <$BF          lecture bit 3              (4)
  ROLA                pousser dans A             (2)
  CMPB  <$BF          lecture bit 2              (4)
  ROLA                pousser dans A             (2)
  CMPB  <$BF          lecture bit 1              (4)
  ROLA                pousser dans A             (2)
  CMPB  <$BF          lecture bit 0              (4)
  ROLA                pousser dans A             (2)
  RTS                 retour octet dans A        (5)

*------------------------------------------------------
* ECRITURE D'UN OCTET (SDDRIVE) = 50 + 5 cycles
* Le registre B est preserve
* Valeur de l'octet dans le registre A en entree
*------------------------------------------------------
WBYTE
  ROLA                b7 dans carry              (2)
  ROLA                b7 dans b0                 (2)
  STA   <$BF          ecriture bit 7             (4)
  ROLA                b6 dans b0                 (2)
  STA   <$BF          ecriture bit 6             (4)
  ROLA                b5 dans b0                 (2)
  STA   <$BF          ecriture bit 5             (4)
  ROLA                b4 dans b0                 (2)
  STA   <$BF          ecriture bit 4             (4)
  ROLA                b3 dans b0                 (2)
  STA   <$BF          ecriture bit 3             (4)
  ROLA                b2 dans b0                 (2)
  STA   <$BF          ecriture bit 2             (4)
  ROLA                b1 dans b0                 (2)
  STA   <$BF          ecriture bit 1             (4)
  ROLA                b0 dans b0                 (2)
  STA   <$BF          ecriture bit 0             (4)
  RTS                 retour
Dans la routine d'écriture le registre B n'est pas modifié, c'est un avantage car il peut être utilisé comme compteur (ou autre usage) dans le programme appelant.
Daniel
L'obstacle augmente mon ardeur.
Lesarthois
Messages : 203
Inscription : 13 mai 2016 22:21

Re: [Thomson] SDDRIVE

Message par Lesarthois »

Mes connaissances en électronique sont limitées; mais de ce que je lis, le circuit a besoin de 4 volts, pas plus... et pas moins.
Des résistances limitent le courant autant que la tension, donc a moins de savoir exactement ce que le circuit consomme, trouver la bonne valeur de résistance est un peu du hasard...
Les LED sont des diodes, elles ne limitent pas la tension ni l'intensité, seulement le passage du courant (bon évidemment, elles doivent consommer quelque chose, mais ce n'est pas le rôle d'une LED de servir de résistance ou de transformateur).
Les diodes au Germanium provoquent une chute de tension de 1.2 volts, ce qui est apparemment aussi le cas d'une LED.
A défaut de trouver autre chose, cela pourra remplacer la LED.
Une diode ordinaire au silicium provoque une chute de tension de 1.7 volts, donc il faut bien trouver une diode Germanium. En général elles sont très reconnaissables car elles ont une enveloppe de verre :
Image
On les trouve encore couramment dans les appareils audio.
Pour les amateurs, la diode germanium remplace très bien le cristal de galène dans les montages de radio à galène :)
Daniel
Messages : 17319
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [Thomson] SDDRIVE

Message par Daniel »

Les circuits logiques "Low power Shottky" utilisés par l'interface SDDRIVE ont des caractéristiques bien précises, en particulier la tension d'alimentation est 5V (plus ou moins 5%). Il n'est pas possible d'envisager une alimentation 4V, elle serait hors normes.

Le problème n'est pas d'ajuster la tension d'alimentation, mais de trouver pourquoi la carte SD ne répond pas à la commande CMD0 alors que l'analyseur logique montre qu'elle est envoyée correctement. Et que le même circuit avec la même carte SD fonctionne parfaitement bien sur le MO5. C'est probablement assez subtil, et pour l'instant je ne sais pas trop comment procéder. Voici le schéma de l'interface :

sddrive_test_schema.png
sddrive_test_schema.png (15.69 Kio) Consulté 6503 fois
[Edit]
Après avoir ajusté l'alimentation du TO8 à 5V j'ai fait ne nouveaux essais, et le signal d'horloge SCK mesuré à l'oscilloscope me semble anormal : il paraît trop court (moins d'une µs) et sa forme est plus triangulaire que rectangulaire. Il faut trouver pourquoi...
Daniel
L'obstacle augmente mon ardeur.
Avatar de l’utilisateur
gleike
Messages : 1341
Inscription : 16 oct. 2014 11:12
Localisation : Ludres (54710) Meurthe & Moselle

Re: [Thomson] SDDRIVE

Message par gleike »

As-tu essayé de changer de module catalex SDcard ?

j'ai le même analyseur logique que toi, et son insertion dans un circuit n'est pas anodine
et provoque des dysfonctionnements,
j'en ai fait l’expérience en réparant mon MO6,
avec l'analyseur connecté sur certains signaux, l'ordinateur ne voulait plus démarrer du tout.
Dernière modification par gleike le 29 nov. 2017 15:48, modifié 1 fois.
Répondre